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PREFACE 


Since the initial implementation of the Apollo Program Config- 
uration Management requirements in May 1964 (through former 
NPC 500-1) , significant progress has been made in developing 
this system. The initial requirements established by the 
Apollo Program Office/ supplemented by the MSF field instal- 
lations* requirements/ have led to the establishment of a 
specification program and change control system that are effec- 
tively helping to control program performance, costs, and sched- 
ules. 

This publication, which basically revises and supersedes NPC 
500-1, includes improvements based on our experience and repre- 
sents the final phase in the implementation of configuration 
management on the Apollo Program. This publication contains 
the latest requirements which are considered necessary, as a 
minimum, to effectively manage the configuration of all Apollo 
end items. This revision accomplishes the following main 
purposes: 

a. Reduction of all exhibits to "minimum requirements" for 
adequate configuration management. 

b. Recognition of field installation supplements to the former 
NPC 500-1. ■ 

c. Addition of configuration management requirements for com- 
puter programs. 

d. Alignment of future Apollo configuration management require- 
ments with the overall NASA concept of Phased Project Plan- 
ning (PPP) . 

e. Definition of configuration management intercenter inter- 
face responsibilities. 

f. Establishment of a configuration management audit system. 

g. Recognition of recent Department of Defense (DOD) configur- 
ation management policy manuals, standards and specifications. 

This publication shall not cause any changes to be made to 
existing contracts. However, on additions to current contracts 
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and new contracts, it should be implemented to the extent 
practical . 

Superseded Document 

NPC 500-1, dated May 18, 1964 and February 1967 Reprint are 
canceled. 
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APOLLO PROGRAM 

CONFIGURATION MANAGEMENT MANUAL 


1.0 POLICY 

This document revises and supersedes NPC 500-1 "Apollo 
Configuration Management Manual" , dated May 18, 1964. 

The definition and applicability of configuration management 
procedures shall take into consideration the scope of the 
effort in terms of costs and complexity, the degree to which 
a project has progressed towards completion, and the config- 
uration management procedures now in effect. 

Contracts initiated subsequent to the effectivity date of 
this document may at the option of individual using agencies 
require compliance with the following Department of Defense 
documentation : 

° MIL-S-83490 "Specification, Types and Forms", dated 

30 October 1968 

° MIL-STD-480 "Configuration Control - Engineering Changes, 
Deviations and Waivers", dated 30 October 1968 

° MIL-STD-481 "Configuration Control - Engineering Changes, 
Deviations and Waivers (Short Form)", dated 
30 October 1968 

° MIL-STD-490 "Specification Practices", dated 30 October 1968 

° Other DOD documentation, newly released, as it becomes 
available for guidance. 

Exceptions to DOD documentation requirements: 

a. For the preparation of "Program", "Project", and "System" 
specifications required by NASA contracts; compliance 
with the requirements, instructions, and format detailed 
by Exhibit I of this document shall apply. 

b. Where NASA requires the preparation of "two part" speci- 
fications, such specifications shall be prepared in 
accordance with the exhibits of this document which 
relate to the preparation of "two part" specifications. 
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2.0 PURPOSE 


This manual establishes the configuration management require- 
ments which will accurately define all Apollo Program end 
items at any point in time. Accurate definition of equipment 
is the basis for establishing schedules, developing realistic 
budget requirements and for accomplishing effective change 
control throughout the life of the program. 

3 . 0 APPLICABILITY 

The requirements established herein are applicable to all 
NASA organizations and contractors participating in the Apollo 
Program. 

4.0 . GENERAL 

Revisions to various exhibits have been made based on Program 
needs and experience in applying configuration management on 
Apollo since 1964. Configuration management provides for all 
levels of management the necessary procedures and disciplines 
to achieve effective control over all space vehicle and ground 
system products fabricated for the Apollo Program. This con- 
trol is needed on a continuing basis from initial definition 
of a product to the final use of the specific hardware and 
software, and is provided by: 

a. A Configuration Identification Baseline System which 
defines, through specifications and associated data, the 
requirements for all end items. 

b. A Configuration Control System which controls all changes 
to the end items. 

c. A Configuration Accounting System which documents all 
changes to baseline configurations and maintains an accurate 
record of configuration change incorporation. 
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4 . 1 Apollo Baseline System 

A fundamental concept of configuration management is 
the establishment of "baselines" to serve as a point 
of departure for controlling subsequent performance 
and design changes from that baseline. Apollo uses 
three (3) baselines for establishing requirements, all 
documented by approved specifications. Once these 
baselines are defined, changes in requirements must be 
formally approved to insure adequate consideration of 
program impact with respect to contract costs, schedules 
and incentives as well as mission capability. Figure 1 
identifies the three (3) Apollo baselines with respect 
to current Apollo phasing, and the types of changes 
required to each. Due to the nature of the Apollo R&D 
program, baselines are not provided at a definite period 
(such as end of the definition phase) but are completed 
in an incremental manner as specific end items such as 
stages/modules are developed. A major configuration 
management task in the baseline system is to identify the 
technical documentation defining the approved configu- 
ration of the system or end item throughout the period 
when hardware/software is acquired. Based on the design 
reviews performed, a baseline for a given end item is 
established and the specific documentation constituting 
that baseline is recorded. The configuration of the 
end item at any later date is identified by the original 
baseline configuration plus all the ensuing changes ap- 
proved and incorporated since that time. The configura- 
tion of an end item will be known and thoroughly documented 
at any given point in time. Another task is the accomplish- 
ment of a minimum set of reviews and inspections necessary 
to validate the accuracy and adequacy of all baselines. 

PDR's and CDR's are self-explanatory and are defined in 
Exhibit XIV. The First Article Configuration Inspection 
(FACI) must be interpreted and applied to the Apollo Program 
as a function of the developmental status of each major end 
item. The end item to be FACI'd should be chosen based on 
the knowledge that, from this item on, subsequent end items 
will require identical performance repeatibility . The FACI 
must establish the exact relationship between the chosen 
CEI (identified as the baseline configuration for subsequent 
items) and the configuration of the CEI (s) used for 
qualification testing if different. In addition, the 
contractor must satisfy the procuring agency that the 
physical hardware for each end item is built to the exact 
engineering drawings and specifications associated with 
that end item. Changes can be made to the CEI FACI'd 
through the procedures and requirements established in 
Exhibit IX. Delta-FACI's (e.g. a FACI on a subsequent CEI 
in the area in which changes have been made) may be conducted 
if necessary. FACI * s are not intended to demonstrate that 
CEI 1 s can perform according to specifications or can 
accomplish the mission requirements. The FACI should prove 
only that the CEI is built according to requirements and 
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has an identifiable relationship with an equivalent 
CEI(s) which was qualified by test. The requirement in 
the original version of this manual for the Final Config- 
uration Review (FCR) has been made an option (to be con- 
ducted as required by a Center) . Two reviews which occur 
during the operational phase, the DCR and FRR are defined 
in Apollo Program Directive Nos. 7 and 8, and require inputs 
from configuration management functions concerning 
configuration status, open items and associated data. 
Requirements on the selection and control of Contract 
End Items (CEI) are found in Paragraph 8. 

4 . 2 Apollo Change Control System 

The control of changes to Apollo hardware/software is 
achieved through the use of the multi-level change 
control system shown in Figure 2. Six levels of control 
are established each of which has specific criteria for 
submitting changes to the next higher level for approval. 

The requirements for submitting changes to the APO CCB 
(Level I) are defined in Paragraph 5.1.3. Each MSF Center 
has established Level II and subordinate CCB's as defined 
in individual Center supplements to this document. (See 
Paragraph 5.2.4.) Additional requirements for submittal 
of changes to the APO CCB and to MSF Center CCB's are 
published from time to time in appropriate APO directives 
such as Apollo Program Directive No. 34. Configuration , 
control is the systematic evaluation, coordination and 
approval or disapproval of proposed changes to any base- 
line. Formal control of the configuration of end items 
starts with the establishment of the Design Requirements 
Baseline and continues through completion of all mission 
objectives . Exhibit IX is a key exhibit in this total 
process since it provides the basis for management 
decision-making after a detail specification for an item 
has been initially approved to define the Design Require- 
ments Baseline for the item. All Class I changes will 
be submitted for approval to the appropriate CCB which 
is the functional body responsible for configuration 
control. The decision of the CCB will be recorded by 
means of a CCB Directive, upon which the Contracting 
Officer will issue the contractual authority for the 
contractor to effect the change. Engineering changes will 
be held to a minimum and should be approved only if nec- 
essary to correct safety hazards, safety of flight or 
necessary to comply with officially approved performance 
requirements. Changes which will result in substantial 
cost savings without compromising safety, performance or 
schedules should receive a high order of consideration. 

4 . 3 Apollo Configuration Accounting System 

Each Center will develop a system capable of reporting 
and documenting the changes made to end items, systems 
and equipment subsequent to the establishment of a base- 
line configuration. Documentation of conf iguration 
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status shall be a systematic record of approved changes, 
with their scheduled incorporation date into the hardware, 
and the actual incorporation date. Configuration Accounting 
Systems must be capable of: 

(a) Defining the exact baseline and all changes 
thereto . 

(b) Providing management personnel with the 
visibility necessary to permit follow-up 
action on decisions to assure proper action 
is taken by appropriate organizations, 
including the providing of feedback infor- 
mation to determine if decisions of the 
various levels of CCB ' s are being imple- 
mented as directed. 

5.0 AUTHORITIES AND RESPONSIBILITIES 

The Apollo Program Office, Configuration Management Office 
(CMO) will provide the over-all management direction required 
to conduct configuration management throughout the Apollo 
Program. Additionally, the Apollo Program Office will 
establish a Configuration Control Board (CCB) to operate 
within the administrative framework of the CMO for making 
decisions on changes requiring Apollo Program Office ap- 
proval. Each Center Program Office will establish a 
Configuration Management Office (CMO) which will be responsible 
for the management direction required to conduct configuration 
management. The Program Manager will establish a Configuration 
Control Board (CCB) to operate within the administrative 
framework of his CMO for making decisions on changes. Specific 
responsibilities for NASA organizations are provided in the 
paragraphs below.. Each contractor will establish a Configuration 
Management Office (CMO) which will be responsible for the 
management direction required to conduct configuration manage- 
ment within the contractor’s organization. The contractor will 
also establish a Configuration Control Board (CCB) to operate 
within the administrative framework of the CMO for making 
decisions on proposed changes. 

5. 1 Apollo Program Office (APO) 


5.1.1 The Apollo Program Director has overall 
responsibility for Apollo Configuration 
Management including: 

5. 1.1.1 Issuing policies and requirements for 
Apollo Configuration Management. 

5.1. 1.2 Establishing a Program Office CMO and CCB. 

5.1.1. 3 Acting as Chairman of the CCB or desig- 
nating a representative with decision 
authority for changes requiring Program 
Office approval. 
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5. 1.1.4 Establishing and controlling intercenter 
interface requirements and changes to 
these requirements through the overall 
Apollo change control system. 


5.1.2 Configuration Management Office (CMO) , Apollo 
Program Office shall be responsible for: 


5. 1.2.1 Establishing Configuration Management 
operating methods and procedures and 
issuing the Apollo Configuration Manage- 
ment Manual to be implemented by all 
NASA organizations and contractors 
participating in the Apollo Program. 


5. 1.2. 2 Assuring management compatibility of 
the configuration management systems 
established by the Centers, and coor- 
dinating intercenter configuration 
management agreements and procedures. 


5.1.2. 3 Reviewing the operation of Apollo 

Configuration Management and imple- 
menting changes by issuing Apollo 
Program Directives as required. 


5. 1.2. 4 Approving proposed Center Supplements 
to the Apollo Configuration Manage- 
ment Manual. 


5.1. 2. 5 Assuring that the Specification Program 
is defined and implemented. 

5. 1.2. 6 Assuring that requirements in Project 
specifications are consistent with 
requirements in the Apollo Program 
specification . 

5.1.2. 7 Maintaining and distributing records of 
Program CCB agendas, ECP actions, 
directives and minutes of CCB meetings. 

5. 1.2. 8 Assuring that follow-up action has been 
taken on Directives issued by the Apollo 
Program Director and/or the CCB. 

5.1.2. 9 Assuring that intercenter interface con- 
trol is operating as an integral part of 
the Apollo change control system. 

5.1.2.10 Conducting audits of MSF Center and 
contractor Configuration Management Sys- 
tems, when deemed appropriate 
(Exhibit XV) . 
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5.1.3 Configuration Control Board (CCB) , Apollo 
Program Office 


5. 1.3.1 The Apollo Program Office CCB is the 
Level I CCB , and as such reviews and 
approves all changes that: 


5.1. 3.1.1 Affect the requirements 

established in the Apollo 
Program Specification. 


5.1. 3.1.2 Affect the launch date. 


5.1. 3. 1.3 Affect controlled milestone 
dates or hardware quantities 
as defined in Apollo Program 
Directive No. 4 (series) . 

5.1. 3.1.4 Result in a contract document, 
modification or supplemental 
agreement whose estimated 
dollar cost will require that 
the document, modification or 
supplemental agreement be 
submitted for Headquarters 
approval per NPC-400. 

5.1. 3. 1.5 Are proposed for Apollo Space 
Vehicles at KSC per Apollo 
Program Directive No. 34 
(current issue) . 

5.1. 3. 1.6 Are proposed for Apollo Hard- 
ware and Software for Saturn/ 
Apollo Applications per Apollo 
Program Directive No. 18J 

5.1. 3.1.7 Concern the assignment of In- 
Flight Experiments to Apollo 
Space Vehicles. 

5.1. 3.2 The Level I CCB will review and approve 
procurement plans submitted to Headquarters 
for approval. 

5.1.3. 3 The Level I CCB will assure that changes 
which have been submitted that have Inter- 
Center interface aspects have been coor- 
dinated and agreed upon by each Center. 

5. 1.3. 4 The Level I CCB will formalize decisions 

by issuing a CCB Directive to the appropriate 
Center CMO (s) . 
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5.2 Center Level Program Offices 


5.2.1 The Program Managers at the Centers shall be 

responsible for: 

5. 2. 1.1 Establishing a Configuration Control 
Board (CCB) and as required subordinate 
Level Boards. 

5. 2. 1.2 Appointing a Chairman for the CCB who 
shall have decision-making authority for 
CCB action. The chairman of the Board 
will designate membership. 

5. 2. 1.3 Providing support to the CCB for the 
technical evaluation of ECP's. 

5. 2.1.4 Establishing a Configuration Management 
Office . 

5. 2.1. 5 The conduct of design reviews and 
establishing the Design and Product 
baselines. 


5. 2. 1.6 The conduct of acceptance and inspection 
tests at the contractor's facility and 
assuring that the equipment has met the 
acceptance requirements prior to shipment. 

5. 2. 1.7 Issuing via the Contracting Officer 
necessary contract changes to implement 
the Configuration Control Board Directives 
(CCBD 1 s) . 


5.2.2 Center Level Program Offices , Configuration Manage- 
ment Office (CMO) shall be responsible for: 


5. 2. 2.1 Establishing Center and contractor procedures 
and supplements in compliance with the 
Apollo Configuration Management Manual. 


5. 2. 2. 2 Initiating and completing the specification 
program and the establishment of the 
official specification files. 


5.2.2. 3 Assuring that requirements in System/CEI 

Specifications are consistent with require- 
ments in Project Specifications. 


5.2. 2. 4 Establishing internal approval/change 
procedures for specifications and main- 
taining specification status documentation. 

5. 2.2.5 Maintaining a file of record which will include 
the result of every ECP action. This file 
will become a permanent part of the appli- 
cable Contract End Item File. 
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5. 2. 2. 6 Reviewing, approving and monitoring 
contractor configuration identification , 
control and accounting procedures. 

5. 2. 2. 7 Insuring that adequate controls and safe- 
guards have been established by each 
contractor for control of Class II changes. 

5.2.2. 8 Approving, issuing and maintaining the 
Configuration Identification and Status 
Accounting Indices; CCB agendas, directives, 
and minutes of meetings. 

5. 2. 2. 9 Assuring that follow-up action has been 
taken on the directives issued by the CCB. 


5.2.3 Center Level Program Offices, Configuration Control 
Board (CCB) shall be responsible for: 


5. 2. 3.1 Approving, rejecting or deferring for further 
study all Project and End Item Specification 
and Equipment/Facility Change Proposals. 


5. 2. 3. 2 Evaluating each proposed change from all 
aspects, e.g., technical, interface, 
logistics, schedule impact, cost, technical 
data, contractual, etc. 


5.2. 3. 3 Coordinating with the appropriate Apollo 

Interface Coordination Panel those changes 
with Inter-Center interface impact prior 
to approval and issuance of a CCB Directive. 


5.2. 3.4 Submitting, with recommendations, those 
changes affecting the items set forth in 
paragraph 5.1. 3.1 to the Apollo Program 
Office CCB for approval. 


5.2. 3.5 Formalizing all decisions by issuing a 
Configuration Control Board Directive. 

The Directive will establish the require- 
ments for concurrent action with respect 
to development, production, and retrofit 
requirements to systems/equipments 
(including training items, ground equip- 
ment, peculiar tooling, spares, spare parts, 
revisions to technical manuals, engineering 
and technical data and software end items) , 
and on the methods of accomplishing the 
changes . 


5.2. 3.6 Operating within the administrative frame- 
work of the CMO. 
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5.2.4 Authorized Center Supplements 


Approved MSF Center Configuration Management 
Manuals and Plans are recognized as official 
center supplements to this manual and will be 
implemented by the appropriate centers. 


6.0 INTERFACE MANAGEMENT 


Configuration management plays a key role in the control of 
inter-center and internal center interface requirements and 
changes. The importance of control over interfaces is 
reflected in the Apollo Program's official definition* -of 
Interface Control Documents: "ICD's are documents estab- 

lishing inter-center joint agreements for interface require- 
ments and are controlled in that these interface require- 
ments cannot be unilaterally changed. These documents must 
be referenced or included in appropriate Apollo-Saturn 
Specifications (e.g.. Project, CEI Specs) to ensure that all 
changes having program/project impact are processed through 
normal Center change control procedures." In addition the ICD 
criteria requires that any changes to interface control require- 
ments, (physical, functional, design, etc.) which will have an 
impact on hardware or software performance, cost or schedule 
accomplishment must be controlled through CCB ' s at all affected 
Centers to assure that all sides of the interface are fully 
coordinated and informed. The organizational and policy 
requirements for Interface Management are contained in APD 
47, (current issue). 


Interface Management shall be accomplished in four distinct 
phases: Identification, Documentation, Implementation and 

Control. The Identification phase shall consist of the 
determination of the existence and the necessity for control 
of an interface. The Documentation phase is the period in 
which ICD's are prepared. The interfaces shall be so defined 
as to assure complete design compatability . The ICD's are to 
be prepared and released in accordance with procedures contained 
herein. The Implementation phase is that part of the program 
during which interface requirements, as defined by the ICD's 
and engineering change control requirements, are contractually 
imposed on design organizations and/or contractors to establish 
an interface baseline. The Control phase is that part of the 
program which requires approval of proposed changes to interface 
requirements in order to prevent unilateral changes which could 
result in incompatible interfaces. 

As . an example, Apollo Inter-Center Interface Control Documents 
shall include but not be limited to the following interface areas: 


Launch Vehicle to 

Q Ball 
Q Ball 

Spacecraft GSE 
Spacecraft 
Launch Vehicle 
Space Vehicle 
Spacecraft 


Spacecraft 
Spacecraft 
to Launch Complex 
Launch Complex 
Launch Complex 
Launch Complex 
Launch Complex 
LVGSE 
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Launch Vehicle to 

Spacecraft 

Launch Vehicle GSE 

Space Vehicle GSE 

Spacecraft GSE 

Spacecraft 


Manned Space Flight Network 
KSC Industrial Area 
Launch Complex 
Launch Complex 
Launch Vehicle GSE 
Manned Space Flight Network 


Each center shall prepare and implement intracenter ICD's 
between Center-level interfacing end items, their applicable 
ground support equipment and any hardware, software or 
documentation elements not categorized as end items which 
are under cognizance of or affect two or more contractors. 
Intra-center ICD's shall be compatible with inter-center 
ICD's at and where mutual interfaces exist. Intra-center 
ICD's, or changes thereto, shall not be approved prior to 
approval of any affected inter-center ICD, or change thereto. 


The Inter-Center Coordination Panels have the responsibility 
to coordinate, maintain, and technically approve all Inter- 
Center interfaces between affected NASA Centers. The Panels 
are charged with initiating the original preparation of, and 
preparing all revisions to, Interface Control Documents. The 
Panels must assure technical compatibility for physical, 
functiorial and procedural interface aspects from the contractors 
through the appropriate NASA Centers. The Panels are formed 
to make available the technical competnece of APO, MSFC, KSC 
and MSC, and their contractors, for the solution of the inter- 
face problems of the launch vehicle, the spacecraft, facilities, 
and associated equipment. 


The Inter-Center Repository receives, records, reproduces, 
and distributes all Apollo Inter-Center ICD's/IRN's approved 
by the Coordiantion Panels and cognizant Center Level II 
CCB ' s . 


7.0 COMPUTER PROGRAM CONFIGURATION MANAGEMENT 

While the configuration management requirements defined in this 
manualdeal both with hardware and software (computer programs) , 
it has become necessary on the Apollo program (as a result of 
the increasing use of "computer — based" systems) to amplify 
these requirements in terms more generally usable by computer 
program technical and management personnel. The basic product 
requiring control is a computer program contract end item 
(CPCEI) , which is defined as the result of a computer program- 
ming process leading to production of a punched deck of cards, 
magnetic tape, or other physical media containing an ordered 
set in a form suitable for insertion into a digital computer. 
Computer programming usually requires the development of 
several programs and the data essential to their use. A 
particular application (e.g., automatic checkout of a launch 
vehicle, onboard guidance and navigation) may require the 
development of: 
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Operational program(s) which perform(s) the required tasks 
(e.g. , generation of trajectory calculations, test- 
stimuli, etc.). 

A data base which contains all the static and dynamic data 
supplied to the operational program (e.g., launch site 
co-ordinates, mathematical constants) . 

Support programs used for the test and evaluation of 
the operational program (e.g., simulation, data recording, 
data reduction programs) . 

Utility programs which include all tools necessary for the 
generation of the operational and support programs (e.g., 
compilers, assemblers, monitors, debugging aids). 

The programs and data form a "programming system." For both 
technical and managerial reasons it is usually desirable to 
partition the total programming system into several CPCEI's. 

For example, the operational program combined with the 
data base may be one CPCEI, a simulation program used to test 
the first CPCEI may be itself a CPCEI, and the set of utility 
programs may be designated as another CPCEI. This selection 
is done by the procuring agency or contractor in the definition 
phase. It results in the allocation of functions to separately 
identified computer programs , . each of which can then be con- 
veniently produced and managed as a unit. Certain characteristics 
of the CPCEI and the process required to produce it affect the 
application of configuration management techniques as originally 
developed for hardware CEI's. Some of the more important 
characteristics are : 

a. Unlike a typical hardware production item, the major 
cost of CPCEI development is in the design and 
testing process. Fabrication of a computer program - 
the punching of cards or paper tape - is usually a small 
part of total development cost. Even in the case where 
many copies are required, production in the sense of 
making additional copies is a routine matter of 
reproducing the program on a computer. This does not 
usually require a detailed specification or engineering 
drawings as does the production of duplicate hardware 
items . 

b. The fabrication of a prototype computer program is 
based, in general, on handwritten coding sheets which 
contain a list of the program instructions. These 
coding sheets, produced in the design process, are 
usually discarded after the entire program is assembled. 
They are replaced by listings generated as a normal 
part of the assembly process. The printer-generated 
listings provide the only accurate record of the 
program configuration. To some degree, then, assembly 
is a self-ddcumenting process. However, a program is 
usually so complex that supporting documents written 

by the programmer are required to make the listings 
understandable to computer personnel. 
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c. Experience has indicated that the volume of changes 
to a CPCEI during its life cycle can be very high. 

This can be attributed to two factors: 

1. Many systems are designed so that expected changes 
can be handled by computer program modifications 
rather than hardware modifications. 

2. Many computer programs are extremely complex, run- 
ning into tens and hundreds of thousands of 
instructions and data words. Errors are inevitable 
when implementing this large a number of instruc- 
tions. . Failures due to errors may show up 
throughout the entire programming process. 

d. The design and development of large-scale computer 
programs is usually accomplished in a/ modular, fashion. 

The program is divided into “subprograms", called 
computer program components (CPC$ . A modular design 
aids in the debugging process by allowing for iso- 
lation of errors and ensuing changes, and it also 
allows for division of responsibility among several 
programmers . 

e. The concepts of quality assurance, control and relia- 
bility differ from that of hardware CEI's. Some of 
these differences are: 

1. Instructions do not wear out with use; hence, 
there are no logistic requirements related to 
spare parts provisioning, interchangeability, 

‘ substitution, etc. 

2. Inspection of the physical item is not an adequate 
means of verifying the quality of a computer program. 
It must also be tested extensively in an 
environment that closely simulates operating 
conditions . 

3. "Quality control" and "acceptance testing," as 
concepts which have primary significance in 
relation to quantity production of equipment CEI * s , 
do not have a comparable applicability to computer 
programs. The production of uniform copies - for 
example, in multi-site applications - is not 
usually a major problem in CPCEI contracts. The 
major problem is usually the proper adaptation of 
the copies to the individual requirements of each 
site. 

4. The equivalent of military standards for the 
control of production does not exist for computer 
programming. Programming design standards are 
generally produced for and tailored to each effort. 
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The programming process for a CPCEI within a system starts 
in the definition phase and continues throughout acquisition 
and operations. In order to provide computer program configura- 
tion management requirements in a complete, concise and 
integrated form, two exhibits are included herein 
as follows: 

Exhibit XVIII - Preparation of Contract End Item 

Detail Specification (Computer Program) 

Exhibit XIX - Computer Program Identification, Control 
and Accounting 

Requirements stated in these exhibits are to be applied to all 
new computer program procurements, and integrated into ongoing 
programming operations as practical. 

8.0 CONTRACT END ITEM SELECTION AND CONTROL 

A Contract End Item (CEI) is an individual product of the 
contractor or an engineering description thereof which shall 
be formally accepted by the procuring agency. It is normally 
the lowest level of assembly for direct management control of 
the contractor by the procuring agency. The contractor’s 
systems arid procedures for documentation, communication and 
accountability shall tie together and reconcile his engineering 
and production efforts below the contract end item level. 

This will allow management actions to be focused at the contract 
end item level to demonstrate that the requirements of the 
procuring agency (i.e. , for performance of equipment, for 
operation, for maintenance, and for training) are contractually 
fulfilled. The actions, records and documents required for this 
contract accountability are shown in Figure 3. This illustration 
is the basis for the configuration identification requirements 
in this Exhibit. During the proposal or definition phase of 
a program the contractor is involved in recommending levels 
of assembly for control as contract end items. As part of his 
effort, the contractor shall search Federal catalogs and select, 
as his first preference, items of inventory which, can be used to 
meet the requirements for contract end items (or subassemblies 
thereof) . Iteiris of inventory shall preferably be selected for 
use as designed, but will also be selected for modification as 
may be required to meet design requirements and where this 
modification will have a lower total cost impaGt than new design. 
Where possible, new design will provide for maintenance by 
inventoried parts. The use of items already available to the 
procuring agency to reduce program costs, reliability and 
logistic problems is an obvious factor of consideration during 
evaluation or review of the adequacy of a contractor's 
technical efforts. It also allows the requirements in Figure 3 
to be simplified and reduce administrative costs. The contractor 
shall normally select the highest level of assembly of each item 
produced in his plant as a contract end item. This will also 
normally result in reduced administrative costs. This selection 
should consider that: 
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(a) all subassemblies of a CEI should have a 
common mission relationship. For example, a 
special mission package for a space vehicle, 
which provides a separate or additional 
capability to that vehicle may be best identified 
as a separate CEI rather than as a subassembly 

of the vehicle. The package may therby be more 
readily scheduled, allocated and provide better 
visibility of mission requirements and capa- 
bilities. ’ 

(b) the contract end item and its subassemblies 
should have a common installation and operation 
requirement. For example, a radio command and 
control set with both ground and airborne 
packages should be identified by a minimum of 
two CEI 1 s to separately identify ground and 
airborne packages. 

(c) the contract end item normally should not contain 
a subassembly expected to have its own independent 
cycle of changes relating to CEI mission, e.g., 

a launch vehicle programmer, where changes in 
booster trajectory will normally be accomplished 
entirely within the programmer. The programmer 
should be a CEI so that the interchangeability of 
the vehicle and programmer are independently 
identified. This will reduce the cost of drawing 
maintenance and increase the significance of the 
part numbers for both the launch vehicle and the 
programmer. 

(d) the above considerations are provided to illustrate 
that the selection of contract end items requires 
analysis of both technical and administrative 
implications, and that fipal choice is a trade-off. 
There are no rules, other than that a CEI is an 
end product to be formally accepted. 

(e) a contract end item which can be produced in the 
contractors plant shall be complete, delivered 
and formally accepted by the procuring agency at 
the contractor's plant. A facility or contract 
end item of ground equipment which can only be 
constructed in the field shall be formally 
accepted at the site of construction. Field 
installation, checkout and test tasks to be 
accomplished after acceptance are not justifiable 
grounds for extending production or construction 
efforts beyond the factory delivery date.ior the 
Beneficial Occupancy Date. 

(f) after acceptance, all contract end items, spares 
and technical manuals will be Government property, 
and shall be formally controlled as such in 
accordance with the requirements of the procuring 
agency. 


15 



9.0 REPORT REQUIREMENTS 

Basic Configuration Management reporting requirements 
for record purposes are contained in Exhibit XVI. 

These reports do not preclude the requirement for 
other reports which may be necessary for program 
visibility and control. Requirements for new reports 
to the APO will be levied by issuance of Apollo Program 
Directives and will not become exhibits to this 
document unless their purpose and value indicate a 
basic improvement in the operational aspects of 
Configuration Management. 
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PREPARATION OF 

PROGRAM, PROJECT AND SYSTEM PERFORMANCE AND DESIGN 
REQUIREMENTS SPECIFICATIONS 


PURPOSE 

This exhibit provides NASA Apollo organizations and 
contractors with requirements and guidance for the 
preparation of Apollo Program, Project and Systems 
Performance and Design Requirements Specifications. 

SCOPE 

The Apollo Program Specification shall contain technical 
requirements for the program as an entity. Lower level 
specif ications shall contain technical requirements for 
the projects and systems as entities. In this exhibit, 
the words program, project and system are interchangeable 
as applicable. These requirements relate to: 

a. Mission requirements, identification and description 
of the program. 

b. Program performance requirements. 

c. Performance budgets. 

d. Standard requirements applicable to all contractor 
designs . 

e. Program qualification and test requirements. 

These specifications provide the basis for, but do not alone 
govern, hardware design and construction, nor are they to 
be used as the basis for factory acceptance of contract end 
items comprising the system. 

APPLICABILITY 

This exhibit is applicable to all NASA Apollo organizations 
and contractors and shall be used in the preparation of 
performance/design requirements specifications. 

REFERENCE DOCUMENTS 

Defense Standardization Manual 4120. 3-M, "Standardization 
Policies, Procedures and Instructions", April 1, 1966. 

Exhibit X, "Requirements for Configuration Identification 
Numbers" . 
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5. EXPLANATION OF TERMS 
(See Exhibit XVII) 

6 . PROCEDURAL REQUIREMENTS 

Format for the specifications described in this .exhibit 
shall be in accordance with Example "A". Specification 
content shall be in accordance with the following 
paragraphs referenced to Example "A" . 

Preparation of Title Page 

The title page for the specification shall be as shown on 
the sample format. 

Specification Numbers 

A separate and distinct number shall be as shown on the 
sample format and be in accordance with the instructions of 
Exhibit X. 

Preparation of "Section 2, Applicable Documents " 

APPLICABLE DOCUMENTS - List only those documents (specifica- 
tions, standards, drawings, bulletins, manuals, etc.) which 
are applicable to paragraphs within the body of the speci- 
fication. Within the body of the specification, reference 
to these documents shall be made by reference to their basic 
document number, or other definitive designation. 

Preparation of 'Section 3, Requirements” 

This section shall contain the following: 

1. The performance and design requirements for the 
program. 

2. The definition of those major elements which make 
up the program. 

3. The identification of program interfaces. 

4. The allocation of performance budgets and specific 
design constraints to the various elements of the 
program. 
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5. The identification and relationships of Contract 
End Items as required by the level of specifica- 
tion, (i.e., a system specification would identify 
all CEI's of the system while a program specifica- 
tion would only mention certain major CEI's necessary 
for a complete definition of the program) . 

6. The design constraints and standards necessary to 
insure compatibility of program hardware. 

7. The performance requirements related to personnel 
utilization, operation, maintenance and logistic 
support of the program to the extent these define 
or constrain the design of program equipment. 

8. The identification and use of major Government 
Furnished Property to be designed into and redelivered 
with program equipment. 

9. The identification and use of major Government 
Furnished Property to be used with other program 
equipment as an independent entity. 

Requirements shall be stated in quantitative physical terms 
with tolerances which can be verified by subsequent analytical 
test, or demonstrative data, or by inspection of the equip- 
ment and related supporting engineering data. Requirements 
shall be the basis for, and be verified by, the tests 
specified in Section 4. 

Paragraph 3.1 "Performance " 

Program performance requirements shall be specified in terms 
of program characteristics and operability. General intro- 
ductory material may be included in this paragraph. All 
requirements shall be specified in appropriate sub-paragraphs. 
Performance requirements shall be specified to the level of 
detail necessary to clearly establish the program elements, 
limits for design, functional interfaces, and performance 
budgets without imposing inappropriate limitations on 
lower management. 

Paragraph 3.1.1 "Characteristics" 

Characteristics are as defined below. 
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Paragraph 3.1,1.1 "Mission Performance 1 ' 

State the general requirements established for the program 
in relating it to NASA objectives and goals, and the basic 
overall mission requirements which are common to more than 
one program element. The requirements shall include such 
items as mission mode, command mode, payload, launch, 
orbital operations, non-orbital operations, and recovery 
aspects as appropriate. Also included shall be the 
definition of the mission requirements of the program in 
terms bf the relationship to support activities. Critical 
performance interfaces relating program to support activi- 
ties shall be specified in quantitative terms. Specific 
performance parameters peculiar to the program shall be 
specified. Requirements which are peculiar to the program 
shall be specified in quantitative terms and shall not be 
phrased as gbals but rather as requirements. 

Paragraph 3. 1.1. 2 "Logistics 11 

Summarize the requirements established for the program by 
logistics considerations as they affect equipment design. 

The type of maintenance to be performed shall be specified. 
Requirements shall be compatible with the Mission Perfor- 
mance requirements of paragraph 3. 1.1.1 and the Reliability 
requirements of paragraph 3. 1.3.1. 

Paragraph 3. 1.1. 3 "Personnel and Training " 

Specify personnel requirements which must be integrated into 
program design. Requirements shall be the bhsis for contrac 
tor design/development decisions and for determination of 
personnel training and training equipment/facility require- 
ments . 

Paragraph 3.1.2 "Program Definition” 


Program definition shall include: 

a. Incorporation, either directly or by reference, 
of specific products of systems engineering which 
portray the relationships of the items of equip- 
ment to be developed. 

b. Identification of the program elements of the system 
each of which may include one or more contract end 
items, and each of which may be assigned to a differ 
ent contractor or NASA Center for integrated develop 
ment . 


1-4 



EXHIBIT I 


c. Identification of the individual items of equip- 
ment (contract end items) which must be developed 
and thus translate the operational requirements 
into equipment development tasks. (Individual 
items of equipment, CEI's, need not be identified 
in the Program Specification if they are more 
appropriately covered in the Project/System 
Specifications) . 

Paragraph 3.1. 2.1 "Systems Engineering Documentation" 

Incorporate, either directly or by reference, the program 
level functional schematics and the top level functional 
flows. Program level system layout drawings or other 
graphic portrayals which establish the general relation- 
ship of primary systems equipment and facilities shall be 
included. A top level Specification Tree shall be included 
or referenced. (See Figure 1.) Documentation shall be 
included to the level of detail necessary to clearly 
establish the elements of the program and the functional 
interfaces between the elements. 

Paragraph 3. 1.2. 2, “Program Element List” 

List the program elements. (For a program specification an 
element may be a project such as a launch vehicle, space- 
craft, etc.) A single design activity may be made respon- 
sible for more than one program element, but an element 
cannot be split and made the responsibility of more than 
one design activity. 

Paragraph 3. 1.2. 3, "Contract End Item List” 

This paragraph shall include a list of contract end items 
which comprise a project or system. The following infor- 
mation shall be included for each item listed: 

a. CEI number 

b. Nomenclature 

c. The CEI into which it installs. An additional 
listing of major items of government furnished 
property (requirements items) which must be 
delivered as part of the system shall be 
included herein, identified by Federal Stock 
Number if applicable. 
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Paragraph 3.1.3, "Operability 11 

Include performance requirements which are general measures 
of efficiency of the program equipment. 

Paragraph 3*1. 3.1, "Reliability ” 

Specify reliability requirements of the program. These 
requirements shall be stated in quantitative terms, defin- 
ing the conditions under which the requirements are to be 
met. A reliability apportionment model may be included 
to support the apportionment of reliability values. 

Paragraph 3 . 1 . 3 . 2 "Ma inta inability " 

State the quantitative requirements for maintainability. 

The basic approach to maintenance in terms of service and 
access requirements for equipment shall be specified: e.g., 
"maintenance on the launch pad is restricted to removal 
and replacement of the failed unit," etc. It shall 
include ground and space vehicle maintenance concepts as well 
as maintenance and repair cycle requirements. 

Paragraph 3. 1.3. 3 "Usefu l Life " 

Specify the anticipated useful life of a program element 
without reference to anticipated useful life of parts of 
a project or system, e.g., "the intended mission service 
of the launch vehicle is one year." 

Paragraph 3. 1.3. 4 "Natural Environment" 

Standards of natural environment which all program equip- 
ment must be designed to withstand if unprotected from the 
elements shall be specified, e.g., wind loading, precipi- 
tation, ranges in temperature, humidity, atmospheric 
pressure, wind shear, vertical gust velocities, turbulence, 
etc. The standards for space environment shall be included, 
if appropriate, e.g., energy input from solar radiation; 
particle mass and energy spectrums , etc. 

Paragraph 3 . 1 . 3 . 5 "Transportability " 

Requirements for transportability which are common to all 
program equipment to support mission operations, mission 
support operations, and logistics shall be specified. 
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Paragraph 3.1. 3.6 "Human Performance" 


Human performance and engineering requirements for the 
program shall be specified or referenced in applicable 
documents . 

Paragraph 3. 1.3. 7 "Safety " 

Specify those safety requirements established as basic to 
all program equipment, e.g., "all ordnance devices to be 
used as part of this program shall use Class II explosives 
as the energy source." 

Paragraph 3. 1.3. 8 "Dangerous Materials and Components" 

Summarize the requirements established due to the use of 
dangerous materials such as: liquid propellants, solid 
propellants, explosive ordnance, electro-explosive 
devices, toxic, corrosive and/or radioactive materials, 
etc. Typical requirements are: establishment of Inter- 
state Commerce Commission hazard classifications; deter- 
mination of criteria for for safe handling, storage, 
transporting, maintenance, checkout and installation; 
determination of sensitivity levels to the effect of radio 
frequency and electromagnetic fields both internal and 
external to the system; determination of criteria for 
siting of facilities; etc. 

Paragraph 3.1. 3.9 "Induced Environment" 

Specify general induced environment constraints of program 
equipment. For example: "The noise and vibration levels 
associated with the system and its elements in required 
combinations shall be controlled under all source condi- 
tions and usage to levels on tolerance to personnel, 
structure, equipment, and facilities as specified in 
MIL- STD- 80 3." 

Paragraph 3.1.3.10 "Life Support" 

Specify the requirements and constraints of system and 
equipment design to maintain a controlled healthful and 
safe environment and to provide for the sustenance and 
welfare of personnel in accomplishing operations, mainten- 
ance, and control tasks. State specific quantitative levels 
and limitations to be controlled under all source conditions 
and usage levels of tolerance to personnel for such items 
as: noise and vibration; environmental control; composition 
of atmosphere; concentration of noxious compounds; food and 
water supply; oxygen and water regeneration; sanitation, 
personnel hygiene and water disposal; acceleration, shock, 
and vibration; etc. 
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Paragraph 3.2 "Program Design and Construction Standards ” 

Specify minimum program design and construction standards 
which have general applicability to program equipment and 
are applicable to major classes of equipment (e.g., space 
vehicle equipment, ground equipment) or are applicable to 
"particular design disciplines." "Particular design disci- 
pline" is identified with the particular speciality of an 
engineer and the kind of equipment which he designs; e.g., 
mechanical, electrical, hydraulic, etc. To the maximum 
extent possible, established NASA or NASA designated mili- 
tary standards and specifications shall be incorporated. 
Requirements which add to, but do not conflict with, 
specified requirements may be included in individual, con- 
tract end item specifications. Standards may include such 
items as : 

a. .Selection of specifications and standards 

b. Materials, parts, and processes 

c. Standard, commercial and qualified parts 

d. Moisture and fungus resistance 

e. Corrosion of metal parts 

f. Interchangeability and replaceability 

g. Workmanship 

h. Electromagnetic interference 

i. Identification and marking 

j. Storage 

k. Drawing standards 

l. Coordinate system standards 

Design criteria requirements limited to specific disciplines 
may be listed under the following titles: 

a. Electrical 

b. Mechanical 

c. Hydraulic 

d. Civil 

e. "Other Disciplines", etc. 
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Paragraph 3.3 “Requirements for Program Elements " 

Include the requirements for each element of the program. 
Defined requirements for an element shall include a dis- 
crete package of performance requirements, functional 
interfaces and contract end items allocated to one indus- 
trial or NASA organization directly responsible for that 
element. An element may include unrelated items of equip- 
ment where allocations are made to take advantage of 
special capabilities existing in one organization. The 
prinicpal purpose of program elements is to specify and 
fix responsibilities for program performance. They shall 
be so selected that functional requirements peculiar to 
each element and the functional interfaces between elements 
can be specified. The requirements specified in paragraph 
3.2, and subparagraphs thereto, are common to all elements 
and shall not be allocated to individual elements. Require- 
ments specified in paragraph 3.1, and subparagraphs thereto, 
shall be allocated to a single element or allocated among 
the elements. 

Paragraph 3.3.1 "Requirements for Program Element A" 

The title of this paragraph shall include the name of the 
program element. Specify, in appropriate subparagraphs, 
the performance requirements for each functional area of the 
element, e.g., structure, propulsion, guidance and navigation, 
etc. These include requirements allocated and/or budgeted 
from paragraph 3.1 as well as requirements which are peculiar 
to the element and cannot be referenced directly to require- 
ments specified in paragraph 3.1. The interfaces of the 
element being specified with other elements shall be stated. 
Interfaces shall be specified to the level of detail neces- 
sary to permit concurrent and mutually compatible design 
and development of all elements. (See 3.3.1 Example A.) 

(For project/systems specif ications only a separate sub- 
paragraph shall reference a list of all contract end items 
included in the project/system.) 

Paragraph 4.0, "Quality Assurance " 


Requirements for formal test/verification of program per- 
formance and design characteristics and operability shall be 
specified. Requirements may be incorporated by reference to 
such documents as the Apollo Test Requirements, the Apollo 
Reliability and Quality Assurance Program Plan and other 
NASA test and reliability publications. The content of 
this section is limited to the specification of test 
requirements and shall not incorporate, either directly or 
by reference, detail test planning documents and instructions. 
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Test requirements shall include engineering evaluation and 
test requirements which necessitate integrated project and 
system testing in direct support of design and development 
activity. Test requirements with respect to program relia- 
bility shall be detailed as well as test requirements for 
formal qualification of program equipment. 

Requirements shall be specified to the level of detail 
which: 

a. Specifies a verification requirement and the method 
for verifying such performance requirement specified 
in paragraph 3.1.1 and 3.1.3. Tests/verifications to 
demonstrate that requirements specified in paragraphs 3.2 
and 3.3 have been met shall be added only upon specific 
direction of the procuring agency. Tests/verifications to 
demonstrate compliance with requirements which are con- 
tained in Section 4 of Part I of individual contract 

end item specifications shall be added only at the 
specific direction of the procuring agency. 

b. Permits ready identification of each verification 
requirement specified in Section 4 with the appro- 
priate performance requirement in Section 3. 

c. Specifies each requirement for verification to the 
level of detail necessary to establish the scope 
and accuracy of the test method. 

Preparation of Section 5, "Preparation for Delivery " 

Specify requirements for the preparation of equipment for 
delivery which are peculiar to the program and are other 
than standard practice. It shall include specific instruc- 
tions to include such non-standard practice in appropriate 
end item specifications. It may impose requirements to 
comply with standard practice by referencing appropriate 
NASA and military specifications and standards to be used 
as the basis for preparing Section 5 of each contract end 
item specification. 

Preparation of Section 6, "Notes" 

Any information pertinent to the program which should be 
made known as background information shall be stated. 
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Preparation of Section 10 , "Appendix 11 

The Appendix or Appendices shall contain requirements which 
are a part of the specification but which, for convenience 
in specification maintenance, are incorporated as an 
Appendix, e.g., requirements of a temporary nature or of 
limited effectivity. Appendices may be bound as separate 
documents for convenience of handling, e.g., when only a 
few parameters of the system are classified, an appendix 
containing only the classified material may be established. 
Where parameters are placed in the appendix, the paragraph 
of Section 10.0 shall be referenced in the main body of the 
cognizant specification in the place where the parameter 
would normally have been specified. 
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EXAMPLE "A" 


Specification No- 
Dated 


PERFORMANCE AND DESIGN REQUIREMENTS SPECIFICATION 

FOR THE 

(Approved Name) /APOLLO PROGRAM 


Approved By 

(Preparing Activity) 

Date __ 

Contract Number 


Approved By 
Date 


(NASA Office) 
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EXAMPLE "A” 


Specification No, 

Dated 

Page 1 


1. SCOPE 

This specification defines the performance, design and test 
requirements for the Apollo Program as defined by the Apollo 
Program Development Plan. All elements and contract end 
items of the Apollo Program shall conform with these require- 
ments. All requirements shall be fully reflected in sub- 
sidiary Apollo specifications. 

2 . APPLICABLE DOCUMENTS 

The following documents, of the exact issue shown, form a 
part of this specification to the extent specified herein. 

In the event of conflict between documents referenced and 
the content of this specification, the content of this 
specification shall take precedence. 

SPECIFICATIONS 

Federal 

Military 

Contractor 

STANDARDS 

Federal 

Military 

Contractor 

DRAWINGS 

BULLETINS 

OTHER PUBLICATIONS 

Manuals 

Regulations 

Handbooks 

Etc. (Copies of specifications, standards, drawings, 
and publications required by suppliers in con- 
nection with specific procurement functions 
should be obtained from the procuring activity 
or as directed by the contracting officer.) 
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EXAMPLE 11 A 11 

Specification No. 

Dated 

Page 2 

3. REQUIREMENTS 

3 . 1 Performance 

3.1.1 Characteristics 


3. 1.1.1 

Mission Performance 

3. 1.1. 2 

Logistics 

3. 1.1. 3 

Personnel and Training 

Program 

Definition 

3. 1.2.1 

Systems Engineering Documentation 

3. 1.2.2 

Program Element List 

3. 1.2. 3 

Contract End Item List (Project 


and Systems Specifications only) 

Operability 

3.1. 3.1 

Reliability 

3. 1.3. 2 

Maintainability 

3. 1.3. 3 

Useful Life 

3. 1.3. 4 

Natural Environment 

3. 1.3. 5 

Transportability 

3. 1.3. 6 

Human Performance 

3. 1.3. 7 

Safety 

3.1.3. 8 

Dangerous Materials and Components 

3. 1.3.9 

Induced Environment 

3.1.3.10 

Life Support 
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4. 

5. 

6 . 
7. 


EXAMPLE "A " 

Specification No. 

Dated 

Page 3 

3 . 2 Program Design and Construction Standards 

3.2.1 General Requirements (In numbered paragraphs 

as appropriate) 

Selection of Specification and Standards 
Materials, Parts and Processes 
Standard, Commerical and Qualified Parts 
Moisture and Fungus Resistance 
Corrosion of Metal Parts 
Interchangeability and Replaceability 


Workmanship 


Electromagnetic Interference 
Identification and Marking 


Storage 


3.3 Requirements for Program Elements 


3.3.1 (Program Element A) 

3.3.2 (Program Element B) 

(Repeat as necessary to provide a separate 3.3.X 
paragraph for each Program Element) 

QUALITY ASSURANCE 

PREPARATION FOR DELiyERY 
NOTES 

APPENDICES 
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PREPARATION OF 

CONTRACT END ITEM DETAIL SPECIFICATION 
(PRIME EQUIPMENT) 


1 . PURPOSE 

This Exhibit provides NASA Apollo organizations and 
contractors with requirements and guidance for the 
preparation of the detail specification for each 
Contract End Item (CEI) and for the addenda thereto. 

2 . SCOPE 

These instructions define the content and format for 
each of the two parts of the Contract End Item Detail 
Specification (Prime Equipment) . Also included are 
instructions for the preparation of addenda to the 
CEI Specification. 

2 .1 CEI Specification 

Each CEI Specification is made up of two parts: 

Part I - Performance and Design Requirements : 

This Part of the CEI Specification 
shall be used to specify requirements 
peculiar to the design, development, 
test, and qualification of the contract 
end item. 

Part II- Product Configuration Requirements : 

This Part of the CEI Specification 
shall be used to specify exact 
configuration information peculiar 
to the production, quality control, 

acceptance testing, and preparation for 

delivery of each contract end 

item. 

2 . 2 Specification Addenda 

An addendum to a CEI Specification is a "short form" 
specification to establish requirements for a new 
end item, which in terms of performance, design and 
construction is so much like an existing CEI that 
it is practical to restrict design and development 
to a "make from" basis. 

For filing and distribution, an addendum specification 
must always be accompanied by a copy of the specifica- 
tion to which it relates. See sample format "E" . 
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A Contract End Item Detail Specification (Prime Equipment) 
shall be prepared for each equipment or system designated 
as a deliverable contract end item , which cannot be spec- 
ified using the simplified formats for: (1) the Identifica- 

tion Specification (see Exhibit IV) , or (2) the Requirements 
Specification (see Exhibit V) . This Exhibit is applicable 
to development/activation prime support equipment, e.g., 
test site support equipment, equipment instrumentation 
and range instrumentation packages, site activation test 
and checkout equipment, and Direct Support - Real Property 
Installed Equipment (DS-RPIE) . This Exhibit is not 
applicable to contract end items which are facilities. 

CEI Specifications shall be compatible with the Program 
and other performance Specifications of Exhibit I. 

4. REFERENCE DOCUMENTS 


AFM 71-4 

29 May 1968 

"Packaging and Handling of 
Dangerous Materials for 
Transporting by Military 
Aircraft" 

DSM 4120. 3-M 

1 April 1966 

"Standardization Policies, 
Procedures and Instructions" 

Exhibit X 


"Requirements for Configur- 
ation Identification Numbers" 

MIL-D-1000 

1 March 1965 

"Drawings, Engineering and 
Associated Lists"" 

MIL-I-8500 

10 October 1960 

"Interchangeability and Replace- 
ability of Component Parts 
for Aircraft and Missiles" 

MIL-P-116E 

1 November 1965 

"Preservation, Methods of" 

MIL-STD-100A 

1 October 1967 

"Engineering Drawing Practices" 

MIL- STD- 12 9D 

28 December 1964 

"Marking for Shipment and 
Storage" 

NHB 5300-4 (IB) 

April 1969 

"Quality Provisions for Aero- 
nautical and Space System 
Contractors" 

NHB 8080.1 

May 1964 

"Apollo Test Requirements" 

NPC 200-3 

April 1962 

"Inspection Systems Provisions 
for Suppliers of Space Mater- 
ials, Parts, Components and 
Services" 

NPC 250-1 

30 July 1963 

"Reliability P^og^a^ Provisions 
for Space Systems' Contractors" 
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5. EXPLANATION OF TERMS 

(See Exhibit XVII.) 

6. PROCEDURAL REQUIREMENTS 

6 . 1 Contract End Item Detail Specification 

The CEI Specification specifies requirements for a single 
CEI type-model-series. The CEI Specification is composed 
of two distinct parts, each of which has a different use 
in the contractual control of CEI acquisition. Each of 
the two parts, when prepared in compliance with these in- 
structions, is complete in content and format with respect 
to its intended use. The CEI Specification is controlled 
and accounted as an entity, using a single configuration 
chart and a single specification change log (see Exhibit 
VII) . Part I is a product of a program definition phase 
or requirements analysis and is the engineering instru- 
ment used to contract for design and development of the 
CEI. Contractor compliance with Part I is determined by 
evaluation of qualification, reliability and other test 
records. Part II of the CEI Specification is a product 
of the design and development contract. Part II specifies 
the CEI in terms of the detail product configuration require- 
mentsof the item qualified (or to be qualified) under the 
terms and conditions of the design and development contract. 
The integrity of Part II must be established prior to 
its acceptance by NASA. 

Acceptance of equipment by Part II of the specification is 
dependent upon the accuracy with which it specifies detail 
configuration requirements of the qualified (or to be qual- 
ified) CEI, and the adequacy of quality assurance require- 
ments established to control the quality of each individual 
unit of the CEI to be produced. The integrity of Part II 
is established by review. The review (First Article Con- 
figuration Inspection - FACI) is accomplished by cross- 
comparison of the data specified in Part II with qualifi- 
cation, reliability and other test records; and with the 
configuration fabricated as the first unit to be accepted. 

The configuration qualified (or to be qualified) under the 
terms and conditions of the design and development contract 
shall be clearly identifiable with the configuration spec- 
ified in Part II. Part II must be identical to the actual 
configuration of the article to undergo FACI. Part II is 
established as the valid engineering instrument to be im- 
plemented contractually for direct control of the CEI. 
Contractor compliance shall be determined by normal quality 
control procedures. The FACI article and all subsequent 
deliveries shall be accepted in accordance with Part II of 
the Contract End Item Specification. These requirements 
shall take precedence over any other requirements for ac- 
ceptance which may also apply and be in conflict. For 
instructions on the preparation of computer program CEI 
Specifications see Exhibit XVIII. 
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6 . 2 ftddenda to Contract End Item Detail Specifications 

Origination of an addendum to a CEI detail specification 
creates in effect a new specification. It is used when an 
item to be designed and developed is so like an existing 
CEI that it is desirable to restrict design activity to 
the. same criteria with additions/deletions. An addendum 
changes a basic CEI detail specification by adding or dele- 
ting requirements on a paragraph-by-paragraph basis. Addenda 
shall be identified with a specific issue of a basic specifi- 
cation. The specification so created (basic specification 
plus addenda) then becomes controlled and maintained as a 
separate and distinct specification, to be updated and re- 
vised as necessary. 

6 . 3 Detail Instructions for the Preparation of Contract End 
Item Detail Specification , Part I 

The following instructional paragraphs are numbered or other- 
wise identified to refer directly to the sample formats at- 
tached. The sample formats are: 

Sample Format "A” - CEI Specification Part I Title Page 

Sample Format "B" - Part I of CEI Specification 

General deviations from the requirements of this instruction 
require prior approval of the procuring agency. Each CEI 
detail specification which deviates from the general require- 
ments of this instruction shall cite, in Section 10, "Appendix", 
the procuring agency instrument authorizing the deviation. 

"Title Page " - The title page shall conform to sample format 
"A", and include the following information. 

"Specification Number" An identifier unique to this 

CEI. (See Exhibit X) 

" Revision Identification" Sequentially assigned character (s 


"Release Date" 


"CEI Number" 


"Approved Nomenclature" 


"Project and/or System 
Identification" 


to uniquely identify each re- 
vision of the specification. 

Date formally released by the 
preparing agency. 

Contract End Item Number 
(See Exhibit X) 

In accordance with Exhibit X, 
and standard practice. 

List the project and/or system 
or systems which the CEI is de- 
signed to support. For CEI's 
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which cannot be identified 
with specific systems enter 
the phrase, "Not System 
Equipment” . 

"Approval Block" The preparing activity (with 

contract number) and the NASA 
office with engineering respon- 
sibility for the CEI shall vali- 
date the specif ication (Center 
Project Office or equivalent) . 

The title page shall be followed by introductory material 
as appropriate, including the End Item Configuration Chart 
and Specification Change Log. Such introductory material 
shall be followed immediately by Part I of the specification 

Section 1, "Scope" - Begin with the opening sentence/ 
paragraph as shown in sample format "B". Subsequent 
sentence/paragraphs, as indicated by sample format "B" , 
shall briefly describe the intended general use of the 
CEI without direct reference to the system or equipment 
to which it is related. Material included may be des- 
criptive, qualitative and/or quantitative. The primary 
output or use, as well as the primary input or operator 
requirements of the CEI, shall be included. 

Section 2, "Applicable Documents" - Begin with the lead 
phrase contained in sample format "B". List those docu- 
ments (specifications, standards, drawings, bulletins, 
manuals, etc.), which are applicable to paragraphs within 
the body of the specification. Within the body of the 
specification, reference to those documents shall be by 
basic document number and/or other applicable designation 
Refer to Defense Standardization Manual 4120. 3-M for 
further instructions on listing of applicable documents. 

Section 3, "Requirements" - Specify performance and 
design requirements for the CEI. Include the functional 
requirements for the CEI and establish requirements 
which are measures of the efficiency /eff activities of 
the CEI. Define the CEI and specify design constraints 
and standards necessary to assure compatibility of the 
CEI with the total program project or system. For CEI ' s 
which directly support a program, project (s) or system (s) 
performance and design requirements are allocated from, 
identical with, or in recognition of, requirements estab- 
lished by the program, project, or system specification. 
When "system engineering" procedures are a part of the 
contract, the requirements appearing in this Section 
shall be based on the "system engineering" documentation 
developed as a result of "system engineering" procedures. 
Quantitative requirements shall be included within the 
principal sub-paragraphs. 
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NOTE: Referring specifically to CEI 1 s 

which support a project (s) or 
system (s) , it may be desirable 
or necessary to establish re- 
quirements for performance, 
design, and construction which 
exceed minimum requirements 
imposed by the program. When 
such uprated requirements are 
established, they shall clearly 
be identified as uprated require- 
ments. The relationship between 
the uprated requirements and 
minimum requirements necessary 
for the program compatibility shall 
be included in Part I, Section 
6, "Notes", together with the reasons 
therefor. 

Paragraph 3.1, "Performance " - Specify CEI 
performance in terms of functional requirements. 

Include requirements which establish the 
effi ciency /effectiveness of the CEI. Re- 
quirements shall be specified to the level of 
detail necessary to establish limits for de- 
sign. 

Paragraph 3.1.1, "Performance Characteristics" - 
Specify the limiting functional characteristics 
of the contract end item. This includes per- 
formance characteristics which are established 
by, and are the product of analysis, as well 
as performance characteristics which are de- 
termined by design. Descriptive and introductory 
material may be included. Quantitative requirements 
shall be specified in the subparagraphs. 

Paragraph 3.1.1. 1, "Primary Performance Characteristics " 

Specify the primary performance characteristics of 
the CEI. These requirements are the product of 
analysis, stated in terms which do not pre-select 
design solutions. Primary performance characteristics 
are the limiting performance parameters which must 
be specified to constrain design within requirements 
established by primary mission/use of the CEI, e.g., 
for spacecraft, this could include limiting mission 
profiles, etc.; for an engine, this could include 
thrust, thrust to weight ratio , etc. Requirements 
shall be stated in quantitative terms, with 
tolerances, using standard, measurable properties 
of the CEI itself. 
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Paragraph 3, 1,1, 3/ “Secondary Performance 
Characteristics M - Specify the secondary 
performance characteristics of the CEI. 

These characteristics generally pre-suppose, 
or are recorded after , a basic design approach 
has been established, and in this sense are 
a product of the design process. Secondary 
performance characteristics are those 
parameters which are not necessarily mission/ 
use critical, but which may be specified to 
properly constrain complete design of the CEI, 
e.g., for a spacecraft, this could include 
such things as various emergency operation 
characteristics, etc.; for an engine, this 
could include maximum continuous operating 
time at emergency rated power, etc. Requirements 
shall be stated in quantitative terms, with 
tolerances, using standard, measurable properties 
of the CEI itself. 

Paragraph 3.1.2, "Operability "- Specify operability 
requirements , including reliability, maintainability, 
transportability, etc., as well as ability to 
operate in the natural and enforced environments, 
human performance features, safety features, etc. 

For CEI's which directly support a project (s) or 
system(s) , operability requirements are allocated 
from, identical with, or in recognition of, re- 
quirements established by the program specification. 
To the extent practical, such requirements shall 
be incorporated by reference to the program 
specification and program documentation. 

Quantitative requirements shall be specified in 
subparagraphs . 

Paragraph 3. 1.2.1, "Reliability" - Specify 
reliability, in quantitative terms, with tolerances, 
such as mean time to failure based on the system 
reliability measure. All measures will include 
the definition of success probability at a stated 
confidence level, and time periods necessary for 
complete demonstration of reliability requirements. 

Paragraph 3 .1 .2 .2 , "Maintainability " - Specify 
maintainability requirements in quantitative 
terms, with tolerances, e.g., mean time to 
repair; maintenance man-hours per operation 
hour; etc. Include, where applicable, ground 
and airborne maintenance concepts , maintenance 
and repair cycles and service and access re- 
quirements . 
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Paragraph 3. 1.2.3, "Useful Life" - Specify 
useful life requirements for the CEI. Include 
requirements for shelf -life as well as operating 
life, and combinations thereof. 

Paragraph 3.1. 2, 4, "Natural Environment” - Standards 
of natural environment which the CEI is to withstand 
shall be specified, e.g., wind loading; precipitation; 
ranges in temperature; humidity; atmospheric pressure; 
wind shear; vertical gust; velocities; turbulence; 
etc. For CEI's which support a program, project(s), 
or system (s) specification, this paragraph shall cite 
the "Environmental" paragraph of the program, pro- 
ject (s) or system (s) specification, amending it for 
application to this CEI. For CEI's which require an 
artificial environment at all times, this paragraph 
shall be marked "Not applicable -- This CEI requires 
a controlled environment at all times." 

Paragraph 3 . 1 . 2 . 5 , "Transportability" - Requirements 
peculiar to transportability shall be specified. Re- 
quirements peculiar to "transport mode" specified in 
paragraph 3.2. 1.2, "Detailed Interface Definition", 
shall not be redundantly specified. Specify also re- 
strictions on the maximum dimensions of weight of the 
CEI as crated for shipment, and include peculiar or 
unusual tie-down requirements imposed by specified 
methods of transportation. If mobility is a signifi- 
cant feature of the CEI, include the time, in terms of 
man-hours and/or elapsed time, allocated to prepare the 
CEI for transport. Also specify detail requirements 
for packaging and packing for shipment wherein the 
packing and packaging methods themselyes re- 
quire development and qualification. 

Paragraph 3.1. 2. 6, "Human Performance" - Human per- 
formance requirements for the CEI shall be specified. 
For CEI's which directly support a program, project, 
or system, cite the appropriate paragraph (s) of the 
program, project or system specification which estab- 
lish the human performance/human engineering require- 
ments for all program equipments, and incorporate 
requirements peculiar to the CEI. 

Paragraph 3.1.2. 7, "Safety" - Requirements for the 
CEI which must be specified to preclude or limit 
hazard to personnel and/or equipment shall be 
specified. To the extent practical, these 
requirements shall be imposed by citing established 
and recognized standards. For CEI's which directly 
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support a program, project(s) , or system(s) , 
cite the appropriate paragraph (s) of the 
program, project, or system specification which 
establishes program safety requirements, amending 
it for applicability to the CEI . Limiting 
personnel safety requirements peculiar to the 
CEI due to unusual hazard in its manufacture, 
test, transport, storage, operation, or 
maintenance which are not provided by standard 
industrial and NASA practices and regulations, 
and not provided by safety requirements imposed 
by the program, project, or system specification 
shall be specified. These hazards include 
flamability limits, susceptibility to accidental 
explosion, production of noxious or toxic gases, 
use or production of hazardous chemicals, ease of 
access and exit, emergency exit, etc. Equipment 
safety shall be specified by "fail safe" or 
emergency operation requirements. Include require- 
ments for redundancy, interlocks, noise and vibration, 
emergency and stand by circuits, and other requirements 
intended principally to prevent damage to or 
recovery of the CEI itself in the event of 
failure or damage. 

Paragraph 3. 1.2. 8, "Induced Environment" - 
Specify the limiting induced environment criteria 
applicable to the CEI. To the extent requirements 
peculiar to noise and vibration are specified 
in paragraph 3. 1.2. 7, "Safety," they shall not 
be redundantly specified. Include induced environment 
required for transportability and storage. For 
CEI's which support a program, project(s), or 
system(s) , the "Induced Environment" paragraph 
in the program specification shall be cited, 
amending it for application to this CEI. 

Paragraph 3.2, "CEI Definition " - Specify the 
mechanical and functional relationship of the 
CEI to other equipments/facilities and identify 
individual components incorporated in the CEI 
which require individual specifications. 

Paragraph 3.2.1, "Interface Requirements " - 
Specify, either directly or by reference, 
requirements imposed on the design of the 
CEI because of its functional, physical 
and procedural relationships to other 
equipments/facilities . This includes 
schematic arrangement data which establishes 
limits for detail design, and is the product 
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of program definition. It also includes 
detailed interface definition, which is 
in part the product of design and is 
developed during the design and develop- 
ment phase of the CEI . General and/or 
descriptive data may be included in the 
basic paragraph. Quantitative require- 
ments shall be incorporated in sub- 
paragraphs . 

Paragraph 3 , 2 ■ 1 . 1 , "Schematic Arrangement " - 
The relationship of the CEI to other equipments/ 
facilities with which it must interface, shall 
be graphically portrayed. Incorporate, wether 
directly or by reference, a schematic diagram, 
inboard profile, or equivalent engineering 
drawing of the CEI. The graphic portrayal of the 
CEI shall be accomplished to the level of detail 
necessary to identify the existence of physical 
interfaces between the CEI and other identified 
equipments/facilities and the nature of the 
interface, e.g., mechanical, hydraulic, electrical, 
etc . 

Paragraph 3,2. 1.2, "Detailed Interface Definition 11 - 
Specify in quantitative terms with tolerances, the 
mechanical, functional, and procedural relationship 
of the CEI to interfacing equipment and facilities, 
to the level of detail necessary to permit detail 
design. Mechanical relationship of the CEI to 
interfacing equipment/facilities shall be expressed 
in terms of dimensions, with tolerances of the CEI 
and related equipment/facilities, at the point(s) of 
contact, referenced to a common datum plane or 
point. The means of mechanical connection shall be 
specified, e.g., bolt circle; toggle clamp; mounting 
pad; etc. Tolerances shall be established to permit 
the widest practical latitude in manufacture while 
maintaining the engineering integrity of the CEI. 
Functional interfaces shall specify the input/output 
requirements of the CEI in terms of voltages, 
pressures, accelerations, limiting temperature 
ranges, thermal shock limitations, loads, purity 
requirements for chemicals, etc. They may be the 
result of direct mechanical interconnect of the CEI 
to other equipments/facilities, or they may be the 
result of performance relationship, e.g., auto-pilot 
gain and space vehicle bending modes, ignition 
response and space vehicle pitch and roll rates, etc. 
(in circumstances where there are distinct modes 
for equipment, e.g., storage mode, checkout mode, trans 
port mode, operational mode, emergency modes, etc., 
and the functional interfaces differ with the change in 
mode, the requirements shall be specified in a manner 


11-10 



EXHIBIT II 


to be clearly identifiable with each mode.) Toler- 
ances established for functional interfaces shall be 
as broad as practical to permit use of unsophisticated 
equipment while maintaining the engineering integrity 
of the CEI . Incorporate, either directly or by 
reference, interface control drawings and/or other 
engineering documentation necessary to specify 
the mechanical and functional interfaces of the 
CEI with other equipment/facilities. 

Paragraph 3.2.2, "Component Identification " - 
Identify components, or component equivalent 
items, incorporated in the CEI which, because 
of their engineering or supply significance, must 
be individually specified. List these items within 
the categories established and defined in sub- 
paragraphs. The terms " component" and "property", 
include mechanical assemblies such as motors, 
drives, etc., as well as materials such as hydraulic 
fluids, fuels, lubricants, bonding agents, lox, 
etc., and tapes and/or decks containing computer 
programs, if part of the CEI. (For instructions 
on the preparation of a requirement specification 
for Government-Furnished Property, see Exhibit V; 
for instructions on the preparation of specifications 
for components and assemblies below CEI level, see 
Exhibit VI . ) 

Paragraph 3. 2. 2.1, "Government-Furnished Property 
List" - List the Government-Furnished Property which 
the CEI must be designed to incorporate. The 
listing shall identify the property by reference 
to its nomenclature, specification number, CEI 
number and, if appropriate, its part number. 

The term "Government-Furnished Property" includes 
both components and materials which must be 
incorporated into the design of the CEI. 

NOTE: The GFP list is a product of program 

definition phase and shall be avail- 
able prior to the acquisition (design 
and development) phase. 

Paragraph 3 . 2 . 2 . 2 , "Engineering Cr itical Components 
List^ - - List the engineering critical components 
within the CEI. Engineering critical components 
shall be identified by nomenclature, specification 
number, and, if appropriate, basic part number. 
Components other than those listed as engineering 
critical shall be considered individually qualified, 
for purposes of reprocurement to support the CEI, 
upon acceptance by the procuring agency of the 
CEI itself as a qualified item. 
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NOTE: The contractor will be required to 

submit the specifications for 
engineering critical components 
to the procuring agency for review 
and approval prior to the start of 
qualification of the component. 

The contractor will deliver both 
the specification and qualification 
data for an engineering critical 
component to the procuring agency 
at the time of delivery of the 
qualification data for the CEI 
itself. The identification of 
engineering critical components 
is normally accomplished during 
the program definition phase, 
and should be available prior to 
the design and development phase. 

Paragraph 3. 2. 2. 3, "Logistics Critical Components 
List" - List the logistics critical components 
within the CEI. Logistics critical components 
shall be identified by their nomenclature, 
specification number and, if appropriate, part 
number. 

NOTE: The individual specifications for 

logistics critical components will 
normally be delivered to the procuring 
agency at the time of delivery of the 
qualification data on the CEI itself. 

The procuring agency will establish 
requirements for the selection of 
logistics critical components, and for 
the delivery of specifications for 
them, as part of the design and develop- 
ment contract. 

This paragraph of the specification shall be 
amended to incorporate individual logistics 
critical items as they are identified during 
the progress of design and development. 

Paragraph 3.2.3. "Technical Manuals" - Reference 
Section 6, Part II, which identifies the technical 
manuals which can be identified with the CEI, and 
which are necessary to its operation and maintenance. 

Paragraph 3.3., "Design and Construction" - Specify 
design and construction requirements for the CEI. 

This includes both general design features, e.g., 
dimensions and weight, as well as detail standards 
and specifications, which must be satisfied by the 
design and construction of the CEI. To the maximum 
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extent possible, requirements included, 
other than those included in paragraph 
3.3.1, shall be specified by reference to 
established NASA or NASA-designated military 
standards and specifications. Descriptive 
material may be included in the basic 
paragraph. For CEI's which directly support 
a program, a project(s) or system(s), the 
content of subparagraphs, with the exception 
of paragraph 3.3.1, represents recognition of a 
requirement established within the program, 
project, or system specif ication. The appro- 
priate paragraphs of the program, project, or 
system specification shall be referenced, and 
amended for applicability to the CEI. Intro- 
ductory requirements specified in subparagraphs 
shall include, but not be limited to, the 
following : 

* 

Paragraph 3.3.1, '’General Design features” - 
Specify design features and physical 
characteristics of the CEI, e.g., size, weight, 
shape, individual critical dimensions, etc. 
Requirements specified may be descriptive, e.g., 
"access panels shall not be designed to carry 
primary structural loads," or expressed in 
quantitative terms, e.g., "the nominal diameter 
of the command module shall not exceed 13 feet." 
Requirements shall normally be verifiable by 
inspection of the CEI. Arrangement drawings, 
three-view drawings, list drawings, and equivalent 
engineering documentation may be incorporated 
either directly or by reference. 

Paragraph 3.3.2, "Selection of Specifications 
and Standards" - Specify requirements, criteria, 
and constraints pertinent to the selection and 
imposition of NASA, Federal, military and 
contractor specifications and standards, e.g., 

"all standards or specifications, other than 
those established and approved for use by NASA 
must be approved by the procuring agency prior 
to incorporation into the CEI specification." 

For a list of specifications and standards, 
see Federal Supply Classif ication Listing of DOD 
Standardization Documents or NASA equivalent. 

For use of specifications and standards, see DOD 
Manual 4120. 3-M. For selection and preparation of 
drawings use MIL-D-1000 with NASA Drawing Specifi- 
cation Cover Sheet, and MIL-STD-100. Form 1 , 2 or 
3 drawings in accordance with MIL-D-1000 shall be 
specified by the procuring agency. 
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Paragraph 3.3.3, "Materials, Parts/ and 
Processes " - Specify requirements for, or prohibit 
the use of, individual and/or types of materials, 
parts and processes. Materials, parts and 
processes included in this paragraph shall be 
identified by reference to pertinent specifications 

Paragraph 3.3.4, "Standard and Commercial Parts" - 
Specify requirements pertinent to the use of 
standard and commercial parts. 

Paragraph 3.3.5, "Moisture and Fungus Resistance M - 
Specify moisture and fungus resistance requirements 

Paragraph 3.3.6, "Corrosion of Metal Parts” - 
Specify requirements for the use of protective 
coatings, and other corrosion control requirements. 
Whenever dissimilar metals are in direct contact, 
the method for controlling electrolytic corrosion 
shall be specified. 

Paragraph 3.3.7, "Interchangeability and Re- 
placeability" - Specify requirements for 
components, assemblies and parts of the CEI 
to be interchangeable and replaceable. 

Requirements are for the purpose of establish- 
ing a condition of design, and are not to define 
the conditions of interchangeability that are 
required by the assignment of part numbers. 

For example, "all access plates for the space- 
craft shall be designed to be readily removed 
and replaced by quick disconnects, and shall 
be interchangeable within a type, model, series 
of the spacecraft to the extent required by 
MIL-I-8500. " 

Paragraph 3.3.8, "Workmanship" - Specify the 
general requirements for workmanship incident 
to fabrication of the CEI. These requirements 
shall make the information available to the 
designer so that it will be properly called 
out on drawings and other engineering documentation 
A sample entry might read: "The CEI, including 

all parts and assemblies, shall be constructed 

and finished in accordance with NASA-STD^ 

or MIL- STD . " 

Paragraph 3.3.9, "Electromagnetic Interference" - 
Specify requirements related to electromagnetic 
interference, in terms of the environment which 
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tiie CEI must accept and the environment 
which it generates. 

Paragraph 3.3.10, "Identification and 
Marking” - Specify the identification 
and marking requirements for the CEI. 
Identification and Marking includes 
coding requirements for wiring, plumbing, 
identification and hazardous conditions, 
etc. A sample entry might read: "All 

electrical wiring contained in this CEI 
shall be identified in accordance with 
NASA-STD or MIL-STD 

NOTE: Identification requirements for 

purposes of configuration manage- 
ment will be made a contractual 
requirement as part of the configuration 
management package, using Exhibits X 
and XI, and will not be incorporated 
into the CEI specification. 

Paragraph 3,3.11. "Storage" - Specify 
requirements peculiar to making the CEI storable. 
This shall include, but not be limited to, 
specification of maximum storage duration, 
storage environment, restrictions pertaining 
to maintenance while in storage, etc. To 
the extent that storage environment has 
been specified in paragraphs 3.1.2. 8 and 
3. 2. 1.2, it shall not be redundantly specified. 

Section 4, "Quality Assurance Provisions" - 
Requirements shall include applicable content of 
"Apollo Test Requirements," NHB 8080.1? 

NASA Quality Publication NPC 200-3? 
and NASA Reliability Publication NPC 250-1. 
Requirements for formal verification of the 
performance, design, and construction of the 
CEI shall be specified. Formal verification 
of performance, design, and construction of 
the CEI shall determine acceptance of design 
and development engineering, under the terms 
and conditions of the design and development 
contract. Formal verification of performance, 
design, and construction of the CEI shall determine 
acceptance of design and development engineering, 
under the terms and conditions of the design 
and development contract. Formal verification 
requirements shall be specified to a level of 
detail which: 
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a. Specifies a verification requirement 
and method in Section 4 for each 
performance and design requirement 
in Section 3 of Part I. The methods 

of verification specified shall include 
inspection of the CEI , review of 
analytical data, demonstrations, test 
and review of test data. 

b. Specifies each requirement for verification, 
other than by inspection of the CEI to 

the level of detail necessary to clearly 
establish the scope and accuracy of the 
test method. 

c. Permits ready identification of each 
verification requirement specified in 
Section 4 with the appropriate per- 
formance/design requirement paragraphs 
in Section 3, of Part I. 

d. Allocates verification requirements to 
the subparagraphs. 

NOTE: Formal verification to be specified 

shall not incorporate, either 
directly or by reference, detail 
test planning documentation and 
operating instructions. Re- 
quirements specified shall be 
the basis for preparation and 
validation of such documents . 

Paragraph 4.1, "Phase I Test/Verification ” - 
The term ’’Phase I/Test Verification,” is defined 
to include all test and verification of the CEI, 
other than that accomplished during the formal 
Phase II test (see Paragraph 4.2). Phase I test/ 
verification is sub-divided into the following 
broad types on the basis of primary reasons for 
acquiring the test data: 

a. Engineering Test and Evaluation : An integral 
part of the development process, oriented 
primarily to acquire data to support the 
design and development process, e.g., 
spacecraft structural test, materials 
test, etc. 
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b. Preliminary Qualification Tests; Formal 
tests oriented primarily to achieve interim 
acceptance of performance and design 
characteristics, prior to committing the 
CEI to: (1) manned operation, (2) 
integrating testing with other equipments 
and/or facilities, and (3) a costlv,' 
complete formal qualification program, e.g., 
preliminary flight rating tests for engines, 
preliminary explosive classification tests 
for ordnance and propellants, etc, 

c. Formal Qualification Tests ; Formal tests 
oriented primarily to satisfy specified 
requirements for formal demonstration of 
performance and design adequacy of the 
CEI. 

d. Reliability Tests and Analyses : Formal 
tests and analyses oriented primarily to 
satisfy specified requirements for 
demonstrated reliability. 

NOTE: Data which is included in reliability 

analyses comes from many sources. 
"Reliability Tests," as used herein, 
are limited to testing which would 
not be accomplished except for the 
need for reliability data. Re- 
quirements shall be specified for 
recording data resulting from 
other than reliability tests for 
reliability analysis. 

e . Engineering Critical Component Qualification : 
Formal qualification of identified and 
specified components/assemblies which are 
contained in, and/or are a part of, a CEI. 

All requirements for Phase I test/verification 
shall be included in sub-paragraphs. 

Paragraph 4.1.1, "Engineering Test and Evaluation " 

(or Development Test) - Engineering tests which 
satisfy one or more of the following criteria: 

a. Require use of Government test facilities, 
e.g., verification of requirements 
specified in paragraph 3. 1.2. 4, 
"Environmental," other than Phase II 
testing. 
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b. Are intended to be the only source 
of data to satisfy specific re- 
quirements in Section 3, e.g., static 
test of spacecraft structure to satisfy 
requirements in paragraph 3.1.1. 1, 

"Primary Performance Characteristics," 
and/or paragraph 3.3.1, "General Design 
Features," screen room testing to 
satisfy requirements in paragraph 
3.3.9, "Electromagnetic Interference," 
etc. 

c. Must be accomplished as part of an 
integrated test program involving other 
system/inventory equipment, e.g., 
verification of requirements in 
paragraph 3. 2. 1.2, "Detailed Interface 
Requirements." Routine engineering and 
laboratory tests accomplished in support 
of design and development, which do 

not satisfy one or more of the criteria 
above, shall not be specified. 

NOTE: Requirements for verification 

included in the project or 
system specification, which are 
directly related to require- 
ments specified herein, may be 
incorporated by reference to 
avoid redundancy. 

Paragraph 4.1.2, "Preliminary Qualification Tests " - 
Specify only those preliminary qualification tests 
which require formal recognition by NASA, e.g., 
verification of requirements specified in paragraph 
3. 1.2. 7, "Safety" prior to the introduction of 
the CEI into a Government test facility; pre- 
liminary flight rating tests on engines prior to 
first flight and/or start of formal qualification; 
etc. Preliminary qualification testing accomplished 
by the contractor in support of design and de- 
velopment which does not require recognition by 
NASA, other than that it is within the general 
terms and conditions of the contract, shall not 
be specified. Requirements for preliminary 
qualifications shall reference specific re- 
quirements in Section 3 if these tests are to 
be the formal basis for the verification that 
specific requirements of Section 3 have been 
satisfied . 
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Paragraph 4.1.3, "Formal Qualification Tests" - 
Specify requirements for formal qualification of 
the CEI to demonstrate and/or verify that each 
requirement established in Section 3 has been 
satisfied. The requirements and method of 
verification for each requirement specified in 
Section 3 shall be specified with the following 
exceptions : 

a. The requirement in Section 3 has been 
identified with, and verification that 
it has been satisfied, has been ac- 
complished by, one of the tests in- 
cluded in paragraphs 4.1.1 and 4.1.2. 

b. The requirement in Section 3 is peculiar 
to paragraph 3. 1.2.1, "Reliability." 
Verification of reliability requirements 
shall be treated in paragraph 4.1.4. 

c. The requirement in Section 3 is peculiar 
to Phase II type system testing and will 
be identified in paragraph 4.2. 

Verification of each requirement shall be accomplished 
by inspection, or review of analytical data, or 
by demonstration, or test and review of test data, 
or combinations of these. This paragraph may 
contain a sub-paragraph for each of the principal 
methods of verification, and specify the re- 
quirements of Section 3 to be verified by the 
method. 

Paragraph 4.1.4, "Reliability Tests and Analyses " - 
Requirement for analyses to verify requirements 
of paragraph 3. 1.2.1 which have been satisfied, 
shall be specified. This shall include the sources 
of data, volume of data, and assumptions basic 
to the validity of raw data input, and analytical 
method. Requirements for testing which are to 
be accomplished specifically and solely to acquire 
reliability data shall be included to the level 
of detail necessary to establish the scope and 
accuracy of the reliability data to be acquired, 
and the scope of the test program. 

Paragraph 4.1.5, "Engineering Critical Component 
Qualification" - Identify, for each of the 
engineering critical components listed in 
paragraph 3. 2. 2. 2, the specification which 
contains its formal qualification test re- 
quirements . 


11-19 



EXHIBIT II 


Paragraph 4.2, "Phase II In t egrated Test 
Requirement s" -For CEI's which directly support 
a project (s) or system(s) , this paragraph shall 
identify requirements specified in Section 3 
which cannot be verified until the CEI is 
assembled into or used with other project or system 
equipment, and verification that the requirement 
has been satisfied must be listed as a Phase II 
test requirement* 

Section 5, “Preparation for De l ivery ” - This Section 
is not applicable to Part I of the End Item Detail 
Specification. CEI requirements pertinent to the 
transportation and handling of the CEI, which must 
be incorporated in design, shall be specified in 
paraqraph 3.1.2. 5, "Transportability." CEI requirements 
pertinent to transportation environment and storage 
environment which must be incorporated in design shall 
be specified in paragraph 3.2. 1.2, "Detailed Interface - 
Definition," and paragraph 3.3.11., "Storage," respectively. 
Requirements for preparation of the produced hardware 
for delivery and shipment are contained in Section 5 
of Part II of the specification. 

Section b, "Notes " - This Section shall include 
information which is stated here for administrative 
convenience only, and is not a part of the specification 
for the CEI in the contractual sense, i.e., it shall 
not include requirements which constrain design, 
development, and qualification of the CEI and require 
compliance by a contractor. Information of importance 
to the procuring agency in using the particular 
specification as a contractual instrument for acquisition 
of the CEI, either initially, or for follow-on procurement 
shall be included. 

Paragraph 6 . 1, "Supplemental Information" - 
Background information or rationale which will 
be of assistance in understanding the specification 
itself or using the CEI it specifies, may be included, 
e.g., technical data and/or manual ordering instructions. 

Paragraph 6.2, ''Alternate Source Qualification " - 
When a CEI is fabricated by an alternate source (other 
than the one who initially developed and qualified the 
CEI design) formal qualification testing of the CEI 
will be required to demonstrate and verify the capability 
of the alternate source to produce the CEI to the require- 
ments of this specification without degradation in its 
performance or reliability. (See Part II Paragraph 10.2). 
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Section 10 , "Appendix ” - Requirements specified in the 
Appendix are contractually a part of the specif ication, 
and to the extent they impose requirements on design, 
development and qualification of the CEI, they must be 
satisfied. This section shall include, but not be 
limited to requirements which are: 

a. Bound separately for convenience as in the 
case of a classified appendix or a large 
body of statistical data. 

b. Are of a temporary nature, as in the case 
of an interim performance requirement for 
early test models of the CEI. (Requirements 
peculiar to early test units of the CEI shall 
be specified in the appendix which adds to, 
deletes, changes, or establishes new re- 
quirements applicable to Sections 3 and 4 

of Part I.) Instrumentation requirements 
for the test units of the CEI shall be 
specified only to the level of detail 
necessary to establish the type and total 
capacity, of the instrumentation. Re- 
quirements (with the exception of 
instrumentation) shall be specified to the 
level of detail required by the paragraph in 
Section 3 and 4 of Part I to which they are 
related. 


6 . 4 Detailed Instructions for t he Preparation of Contract 
End Item Detail Specification, Part II . 

The following instructional paragraphs are numbered or 
otherwise identified to refer directly to the sample 
formats attached. The sample formats are: 

Sample Format "C" - CEI Specification Part II 
Title Page 

Sample Format "D" - Part II of CEI Specification 

"Title Page"- The title page shall conform to the 
format of Sample Format "C". The identifying 
information appearing on this page shall be 
identical to the respective element of information 
appearing on the CEI Specification Title Page for 
Part I. 
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Section 1, 11 Scope” - This Section of Part II 
of the CEI Specification shall begin with the 
opening paragraph shown in Sample Format "D" , 
followed by paragraph 1.1, "Product Con- 
figuration Baseline Acceptance". Paragraph 
1.1 shall begin with the statement shown in 
Sample Format "D". 

Section 2, "Applicable Documents" - This 
Section of the CEI Specification shall begin 
with the lead phrase contained in Sample 
Format "D" . Categorization of entries shall 
conform with Sample Format "D". List only those 
documents (specifications, standards, bulletins, 
manuals, etc.), which are applicable to para- 
graphs within the body of the Specification. 

Within the body of the Specification, reference 
to those documents shall be made by reference 
to their basic document number or other appro- 
priate designation. Refer to Defense Standard- 
ization Manual 4120. 3-M for further instructions 
on listing of applicable documents. 

Section 3, "Requirements" - This Section shall spec- 
ify performance, product configuration and stan- 
dards of manufacture, manufacturing processes, 
and production which must be verified at the time 
and place of delivery to establish the quality of 
the CEI as manufactured. Each requirements to 
be specified must satisfy the following criteria: 

a. There shall be a direct means of testing/ 
verifying that the requirement has been 
satisfied in Section 4, Part II. 

b. The test/verification which formally 
demonstrates that the requirement has 
been satisfied shall be accomplished 

at the place of manufacture of the CEI. 

c. The requirements must be verified at the 
time of acceptance to assure that manufac- 
turing control has been maintained, and that 
the CEI, as fabricated, will function to 
satisfy the requirements of its use. 
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d. The requirement shall be specified 
in physically measurable terms, with 
tolerances . 

Introductory material may be included in basic 
paragraph "Section 3" and requirements shall be 
specified in sub-paragraphs. 

Paragraph 3.1, " Performance" - Specify 
performance requirements for the CEI which 
are in consonance with the criteria stated 
in paragraph 3, "Requirements." Performance 
features included herein shall be specified 
at environmental conditions normal to the 
manufacturing process and/or the place of 
acceptance, and not attempt to simulate the 
environment in which the CEI will be used. 

This paragraph shall specify those performance 
features which cannot be assumed as the 
natural consequence of drawing compliance. 
Requirements shall be specified in terms of 
the CEI itself, in terms of physically 
measurable properties, with tolerances. 
Performance requirements may include features 
which must be verified by preassembly, 
station, or manufacturing test/verif ication . 
Requirements for test/verifications, which 
shall be accomplished prior to final assembly, 
may be specified directly, or by reference 
to manufacturing and processing specifications. 
Requirements shall be to the level of detail 
necessary to establish limits for the test/ 
verification method to be specified in 
Section 4, Part II. Individual requirements 
shall be specified in sub-paragraphs. 

Paragraph 3.2, "Product Conf iguration"- 
Specify the product configuration requirements 
for the CEI. Include a listing of Government- 
furnished property incorporated in the CEI 
during fabrication. Specify the production 
drawings for fabrication of the CEI. Standards 
and specifications for fabrication of the CEI 
which define quality and construction which 
is to be a condition of acceptance of the CEI 
shall be included. Basic paragraph 3.2 may 
include descriptive material or material 
included for purposes of continuity. Require- 
ments shall be specified in sub-paragraphs . 
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Paragraph 3,2.1/ "Manufacturing Drawings 1 1 - 
Begin with the statement shown in Sample 
Format "D" . Specify the drawings which 
are the basis for control of production of 
the CEI . The production drawings shall be 
incorporated by reference to the top drawing 
for the CEI. The method of reference shall 
clearly specify that incorporation of the 
top drawing by reference includes all 
drawings and engineering data assembled by 
the top drawing. Drawings specified herein 
shall reflect all engineering changes 
approved for incorporation into the CEI. 

NOTE: This includes changes approved 

by the procuring agency as 
well as changes released by 
the contractor which do not 
require procuring agency approval. 

Drawings specified shall identify by exact 
part number, each item of Government- furnished 
property required for assembly into the CEI 
during the manufacturing process. The top 
drawing to be referenced shall be identified 
to the CEI by including, on the drawing, 
the CEI number, drawing number, CEI 
nomenclature, and code for the design activity 
(Manufacturers" Code Handbook H4-1) . Other 
identifying data may be included. (See 
Exhibit X) . 

Paragraph 3.2.2, "Government-Furnished Property 
List "- Each item of Government-furnished 
property specified for incorporation into the 
CEI during the manufacturing process, by the 
production drawings incorporated in paragraph 
3.2.1, "Production Drawings," shall be identified 
by nomenclature and part number. 

Paragraph 3.2.3, "Standards of Manufacturin g, 
Manufacturing Processes, and Production" - 
Include those standards of manufacture, 
manufacturing processes, and production, 
which, because of their significance, must 
be specifically identified as part of the 
production configuration baseline. Specify 
only those standards and specifications 
which are of such nature that any change to 
them shall be considered as Class I engineering 


11-24 



EXHIBIT II 


change and require prior approval of the 
procuring agency, e.g., standards for 
identification and marking or wiring and 
tubing, since such marking is basic to 
safety and to the preparation of manuals? 
standards for a bonding process, where a 
change may require a requalification of 
the structural integrity of the CEI? etc. 

To the maximum extent possible, require- 
ments shall be incorporated by reference 
to established Government standards approved 
for NASA use. Contractor and/or industry 
standards must be specifically approved 
by the procuring agency prior to in- 
corporation. Requirements shall be 
specified to the level of detail necessary 
to clearly establish limits for the test/ 
verifications to be specified in Section 
4, Part II. Individual requirements shall 
be specified in sub-paragraphs. 

Section 4, "Quality Assurance” - This Section shall 
begin with the paragraph contained in Sample Format 
"D" . It shall include applicable content of "Apollo 
Test Requirements," NHB 8080.1: NASA Quality Pub- 

lications NHB 5300-4 (IB) and NPC 200-3, and 
NASA Reliability Publication NPC 250-1. Specify 
only the specific test/verifications which must 
be accomplished to satisfy all requirements 
specified in Section 3 of Part II. Test/verifications 
to assure control of quality during the manufacturing 
process not specifically included shall be ac- 
complished by routine manufacturing level surveil- 
lance as required by the local representative of 
the procuring agency (NASA Plant Representative, 
or equivalent) . Each test/verification specified 
shall be witnessed, or the contractor record of the 
test/verification reviewed, at time of acceptance 
of each unit of the CEI, hence all tests/verifications 
included are identified as acceptance test 
verifications. Test/verifications shall be ac- 
complished during the manufacturing process, or 
at time of delivery, to establish the quality of 
the CEI as fabricated and assembled. Each test/ 
verification requirement shall be specified to 
the level of detail necessary to: 

a. Identify each test/verification with 

the requirement in Section 3 of Part II, which 
it satisfies. 
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b. Establish the method for each test/ 
verification. Methods of test/ 
verification include inspection, 
demonstration, test or combinations 
thereof. 

c. Establish, for each method related 
to each test/verification, specific 
limits which shall represent a clear 
basis for decision as to the quality, 
and the acceptability, of the CEI. 

d. Establish the accuracy of each test/ 
verification . Introductory material 
may be included in basic paragraph. 

Section 4. Requirements shall be 
specified in sub-paragraphs. 

Paragraph 4.1, "Product Performance and 
Configuration Requirement/Qua 11 ty Veri fetation 
Cross Reference Index" - This index identifies 
each quality verification in Section 4, Part II, 
with the requirement in Section 3 of Part II, 
which it verifies. The index shall be an 
ordered list of the requirements in Section 3 
of Part II, in the order in which they are 
specified and identified by the paragraph number 
establishing the requirement. 

Paragraph 4.2, fl Test/Verif ications n - The test/ 
verifications required to satisfy each re- 
quirement in Section 3 of Part II shall be 
specified. Each inspection, demonstration 
and test shall be specified to a level of 
detail which clearly establishes the validity 
and accuracy of the test/verification. The 
test/verification shall permit a clear , non- 
subjective determination of the quality of 
the CEI. The tests/verifications specified 
in sub-paragraphs shall be specified to a 
level of detail which satisfies the following 
criteria: 


a. Inspections and/or demonstrations shall 
be stated to quantitatively specify 
and define the limits for the ac- 
ceptable condition. In general, 
verification of quality by inspection 
and/or demonstration in support of 
acceptance testing shall be limited 
to verification of construction 
features of the CEI, e.g., inspec- 
tion for proper wire coding; 
determination of specific physical 
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dimensions; inspection of 
production records to verify 
installation of Government- 
furnished property; etc. 

b. Tests shall be specified, in 
quantitative terms with tolerances, 
to the level of detail necessary 

to clearly establish the test 
method, the credibility of the 
test method, the validity of the 
test data, and the actual measure- 
ment values . 

c. Where records generated during the 
manufacturing process are to be 
used as part of acceptance test/ 
verification, the method of establishing 
the validity of the record, as well 

as record content shall be specified. 

Paragraph 4.2.1, "Drawing Compliance” - Specify 
the method for verifying that the CEI, as 
fabricated and assembled is configured to 
conform to the drawings specified in paragraph 
3.2.1 of Part II, and has incorporated the 
Government-furnished property specified in 
paragraph 3.2.2 of Part II. To the extent 
practical, this shall be accomplished by 
inspection at the time and place of ac- 
ceptance of the CEI. The "as manufactured" 
configuration of the CEI's which cannot be 
inspected in fully assembled condition, to 
the level of detail necessary to fully 
establish configuration conformance to the 
drawing (complex CEI's hermetically sealed 
units, electronic equipment assembled into 
cabinets, etc.) , shall be verified by 
reference to manufacturing records (see 
Exhibit XIII) . 

Section 5, "Preparation for Delivery" - Specify the 
requirements for preservation, packaging, packing, 
marking, and otherwise preparing the CEI for ship- 
ment. The levels of packing, are as defined in 
Federal Standard 102. Where approved NASA or 
NASA designated Military Specifications, or 
NASA equivalent, are adequate to satisfy current 
requirements for the item and components thereof, 
a reference should be incorporated in lieu of providing 
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duplicated detailed requirements. Where suitable 
specifications do not exist, requirements peculiar 
to the CEI shall be specified in sub-paragraphs. 

Paragraph 5.1. "Preservation and Packaging” - 
The requirements for preservation and packaging 
shall be specified and shall include cleaning 
and drying as may be required and appropriate 
preservation method selected from Section 3 
of Specification MIL-P-116, or applicable 
NASA Specification. S&ection of proper 
method shall be determined by the charac- 
teristics of the item and anticipated transit 
and storage conditions. Include as part of 
the packaging requirements any appropriate 
wrappings, interior cushioning and unit 
containers. Requirements shall be specified 
in sub-paragraphs to include, but not be limited 
to : 

Paragraph 5.1.1, ’•Cleaning” - The applicable 
cleaning process from paragraph 3.2 of 
Specification MIL-P-116 or NASA equivalent, 
shall be specified. 

Paragraph 5.1.2, "Drying" - The drying process 
applicable to the CEI from paragraph 3.3 of 
Specification MIL-P-116, or NASA equivalent 
shall be specified. 

Paragraph 5.1.3, "Levels of Packaging" - Specify 
the preservation and packaging requirements re- 
lated to each of the specific storage periods 
defined in the following sub-paragraphs. 

Paragraph 5. 1.3.1, immediate Use" - Specify 
preservation and packaging requirements 
incident to preparing the CEI for shipment 
and immediate use at destination. Preser- 
vation and packaging for immediate use is 
defined to be the minimum needed to adequately 
protect the item(s) against environmental 
and physical hazards during handling and 
transit to destination for immediate use. 
Normally, requirements compatible with MIL- 
P-116 will suffice for this level unless, 
because of peculiar item characteristics, 
additional environmental protection is 
required. 
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Paragraph 5. 1.3 .2, "Limited Storage ” - 
Specify preservation and packaging re- 
quirements incident to preparing the 
CEI for shipment as well as limited 
storage. Preservation and packaging 
requirements for this protective level 
shall be sufficient to provide adequate 
protection to the item<s) against en- 
vironmental and physical hazards during 
handling and transmit to destination and 
for a specified storage period. 

Paragraph 5. 1.3, 3, "Extended Storage” - 
Specify preservation and packaging 
requirements incident to preparing 
the CEI for shipment as well as ex- 
tended storage. Preservation and 
packaging requirements for extended 
storage ahall be adequate to protect 
the item(s) against environmental 
and physical hazards during handling 
and transit and under adverse storage 
conditions for an indeterminate period. 

Paragraph 5.1. 3.4, "Intermediate Packaging " 
Requirements for intermediate packaging , 
in preparing the CEI for shipment and/or 
storage , shall be specified. Intermediate 
packaging shall consist of placing a 
quantity of identical unit packages into 
a consolidating or intermediate container 
for ultimate overpacking into an exterior 
shipping container. 

Paragraph 5*2, "Packing” - The requirements 
for packing shall include specification of 
the appropriate exterior shipping container 
and the placement of a specified quantity 
of packages therein, and shall specify or 
otherwise delineate the necessary blocking, 
bracing, and cushioning required. In 
instances where the unit container serves 
also as the exterior shipping container, 
the container shall be specified under 
"Packaging" shall reflect the acceptable 
utilization of the same container to provide 
for two exterior requirements. Packing 
requirements shall be provided for two 
basic modes of transportation and for, as 
applicable, both continental United States 
and overseas movement. In the selection of 
a shipping container, consideration should 
be given to insuring that it is of minimum 
cube required and, insofar as possible. 
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within a 15% maximum in tare weight. 

Paragraph 5.2,1, "Domestic Shipment' 1 - 
The term "domestic shipment" denotes 
movement within the continental United 
States. Include the packing re- 
quirements peculiar to the mode of 
transport. 

Paragraph 5. 2 .1.1, "Air" - Packing for 
domestic shipment by air shall be specified 
and shall be the minimum required to afford 
adequate protection against handling and 
transit hazards normally encountered in air 
shipment . 

Paragraph 5 *2.1, 2, "Surface "- Packing for 
domestic shipment by surface carrier shall 
be specified and shall be the minimum re- 
quired to afford adequate protection against 
handling and transit hazards encountered in 
rail or truck movement. 

Paragraph 5.2.2/ "Overseas Shipment " - The 
term "overseas shipment" denotes movement 
from a point of origin within the continental 
United States to a destination point out- 
side the continental United States, or the 
converse, or point-to-point movement entirely 
outside the continental United States. 

Paragraph 5. 2. 2.1, "Air" - Packing for overseas 
shipment by air shall be specified and shall 
provide adequate physical and environmental 
protection against handling and transit hazards 
normally encountered in shipment via military 
or commercial air. Domestic containers used 
for shipment within the continental United 
States will generally provide the required 
protection . 


Paragraph 5. 2. 2. 2, "Surface M - Packing for 
overseas shipment by surface carrier shall be 
specified and shall provide maximum protection 
to contents against handling, transit, and 
storage conditions encountered in shipment by 
ocean going carriers. 
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Paragraph 5.3, "Shipment" - Shipment 
information and limitations shall be 
specified. This shall include identi- 
fication of special features necessary 
to protect items during movement or 
storage, including, but not limited 
to, trailers, dollies and wheeled 
containers that are designed to 
facilitate handling and installation 
of equipment at destination. Also, 
identify the specific air, ship, or 
ground carrier means of transportation 
if shipment of the end item is to be 
limited to particular modes of transport. 
Where modifications of the transporting 
vehicle are required, this specification 
shall state, "Required modifications to 
{vehicle model number. Federal Stock 
Number, and nomenclature) are to be in 
accordance with (number and title of 
specification describing the mod- 
ification) . " The requirements for 
marking shall cover complete identi- 
fication of the product, both on 
packages and shipping containers, 
normally as required by MIL-STD-129 and/ 
or any other marking requirements as 
directed. All precautionary marking 
required by ICC or CAB regulations, 

AFM 71-4 or necessary marking for 
safety purposes shall be specified 
either in detail or through reference 
to the governing documents or directives . 

Section 6, "Notes " - This Section of the specification 
is not contractually binding. It shall include in- 
formation of particular importance to the procuring 
agency in using Part II of this specification as a 
contractual instrument, or administrative or back- 
ground information, e.g., ordering instructions 
for technical data and/or manuals pertinent to the 
CEI . 

Section 10, "Appendix" - This Section of the 
specification shall include requirements which are 
part of Section 3 and/or 4, but are bound 
separately for convenience, e.g., classified 
material; book form drawings of the computer program 
for automatic checkout equipment; etc. Also include 
requirements established for test units of the CEI 
only. This includes requirements peculiar to ac- 
cepting the CEI in a configuration instrumented 
for test. 
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Paragraph 10,1. "Acceptance Requirements 
for Units of the CET in a Test Configuration " - 
During design' "and development of the CEI, 
individual units of the CEI, in a test 
configuration, must be accepted by the 
procuring agency to recognize transfer 
of accountability and/or permit de- 
struction of the unit in test, or to 
deliver the unit as Government-furnished 
property to a second contractor to permit 
integrated system testing. The format and 
general content of a Part II used for 
purposes of accepting units of the CEI in / 

a test configuration shall conform to the 
requirements established herein for a Part 
II used to accept hardware for the mission. 

Part II* s used as a basis for acceptance of 
units of a CEI in a test configuration shall 
satisfy the requirements for minimum 
specification content contained in 
paragraphs 3.2.1, 3.2.2, and 4.2.1 of 
Part II. Further detail content shall be 
as defined by the procuring agency. Instru- 
mentation requirements shall be included. 
Instrumentation requirements specified shall 
be limited to establishing the total capability 
or capacity of the instrumentation to be 
installed, and the quality of installation, 
and shall not include details of calibration, 
channel assignments, and instruments, etc., 
which change frequently and hence would make 
maintenance of the specification un- 
necessarily burdensome. 

Paragraph 10.2 "Alternate Source Qualification " - 
When a CEI is fabricated bv an alternate source 
(other than the one who initially developed and 
qualified the CEI) verification is required of the 
capability of the alternate source to produce the 
CEI to the requirements of this specification with- 
out degradation in its performance or reliability. 

Such verification shall require the performance 
of complete qualification testing in accordance with 
paragraph 4.1.3 "Formal Qualification Tests", of 
Part I of this speicif ication; or as otherwise 
specified by the procuring agency. 
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6 . 5 Detailed Instructions for the Preparation of Contract 
End Item Detail Specification Addenda 


Frequently, a requirement develops for a CEI which 
is very similar to an existing CEI. When this occurs, 
it is desirable to create the new CEI by accomplishing 
minimum redesign of the existing CEI. To accomplish 
this, it is necessary to maintain visibility through- 
out the design and development cycle of differences 
in performance, design and configuration requirements 
between the two CEI's. This visibility is acquired 
and maintained by creating the specification for the 
new CEI as an addendum to the specification for the 
existing CEI. 

The use of a specification addendum presents a formal 
means of writing a specification for a new CEI by 
changing the specification for an existing CEI in 
a manner which permits ready comparison of the 
exact relationship between two items of equipments. 
This is accomplished by writing the new specification 
by direct reference to the existing specification 
on a paragraph-by-paragraph basis, recording in the 
new specification and noting each addition, deletion, 
change, or where no change is necessary, the words 
"no change". The paragraph numbering between the 
two documents will be identical, with the exception 
of paragraphs added to the new document which do 
not have an exact counterpart in the existing 
specification. 

A specification created in this manner is a new 
and complete specification in every sense. The 
method of preparing a specif ication for a new 
CEI by creating an addendum to an existing 
specification shall be used when the following 
considerations are satisfied; 

a. There is sufficient reason to establish 
direct relationship between the new CEI 
and an existing CEI as a basis for design 
and development, e.g., progressing from 
one type, model, series of a CEI to 
another; minor changes must be ac- 
complished to a very limited number 
of units of a CEI for a specific mission, 
as is the case with space boosters. 
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b. The basic specification, to which the 
addendum is prepared, compiles with 
the requirements of this exhibit, 
with respect to format and content. 

The specification created by use of an addendum must 
be identified and maintained as a separate specification. 
Both the specification created by use of an addendum, 
and the basic specification to which the addendum is 
prepared shall have independent change cycles. A 
specification change notice to either is not auto- 
matically a change to both. Each change to either 
must be reviewed, and if it is desirable to change 
both the basic specification and the specification 
prepared as an addendum, two separate specification 
change notices must be prepared. 

When a new specification is created by the preparation 
of an addendum to an existing specification, an 
"Addendum Notice" shall be prepared which conforms 
to the format and includes the content required by 
sample format "E" . The "Addendum Notice" shall be 
the first entry in Section 2, "Applicable Documents." 

All of the data in the "Addendum Notice" refer to 
the specification used as the basic document for 
preparation of the addenda. Each item of data to 
be entered shall be transcribed from the title 
page and specification change log of the basic 
specification. 

Note: For filing and distribution an Addendum Speci- 

fication must always be accompanied by the 
specification to which it relates. See Sample 
Format "E" . 
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SAMPLE FORMAT "A" 

Specification No. 

Revision No. 

Release Date 

Page 1-1 


CONTRACT END ITEM DETAIL SPECIFICATION 
(Prime Equipment) 

PART I 

PERFORMANCE AND DESIGN 
REQUIREMENTS 

(CEI Number) 


(APPROVED NOMENCLATURE) 
FOR 

(PROJECT OR SYSTEM NAME) 


Approved by 

(Preparing Activity) 

Date 

Contract Number 


Approved by 

(NASA Office) 

Approval Date 
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SAMPLE FORMAT "B" 


Specification No, 

Release Date 

Page 1-2 


1 . SCOPE 

This part of this specification establishes the requirements 
for performance, design, test and qualification of one type-model- 
* series of equipment identified as (insert nomenclature and contract 
end item number) . This CEI is used to (provide) (accomplish) . . . 
This CEI requires . . 

2. APPLICABLE DOCUMENTS 

The following documents, of exact issue shown, form a part 
of this specification to the extent specified herein. In the 
event of conflict between documents referenced here and other 
detail content of Section 3, 4,5, and 10, the detail re- 
quirements of Sections 3, 4, 5, and 10 shall be considered a 
superseding requirement. 

PROJECT AND SYSTEM DOCUMENTS 

SPECIFICATIONS 

Federal 

Military 

Contractor 

STANDARDS 

Federal 

Military 

Contractor 

DRAWINGS 

BULLETINS 

OTHER PUBLICATIONS 
Manuals 
Regulations 
Handbooks 
Etc. 

(Copies of specifications, standards, drawings, bulletins, 
and publications required by suppliers in connection with 
specific procurement functions should be obtained from 
the procuring activity or as directed by the contracting 
officer . ) 
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SAMPLE FORMAT "B" 


Specification No._ 

Release Date * 

Page 1-3 


3. REQUIREMENTS 


Performance 
3.1.1 Per f orman ce v 

3.1.1. 1 Primary Performance Characteristics 

3. 1.1.2 

Secondary Performance Characteristics 

3.1.2 Ope rabi 1 i ty 

3. 1.2.1 

Reliability 

3. 1.2. 2 

Maintainability 

3. 1.2. 3 

Useful Life 

3.1.2. 4 

Natural Environment 

3. 1.2. 5 

Transportability 

3. 1.2. 6 

Human Performance 

3. 1.2. 7 

Safety 

3. 1.2. 8 
CEI Definition 

Induced Environment 


3.2,1 Interface Requirements 

3.2.1. 1 Schematic Arrangement 

3. 2. 1.2 Detailed Interface Definition 
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SAMPLE FORMAT "B" 

Specification No, 

Release Date 

Page 1-4 


3.2.2 

Component Identification 


3. 2.2.1 Government-Furnished Property List 


3. 2. 2. 2 Engineering Critical Components List 

3.2. 3 

3. 2. 2. 3 Logistics Critical Components List 
Technical Manuals 

3.3 

Design and Construction 
3.3.1 General Design Features 


3.3.2 Selection of Specifications and Standards 


3.3.3 Materials Parts and Processes 


3.3.4 Standard and Commerical Parts 


3.3.5 Moisture and Fungus Resistance 


3.3.6 Corrosion of Metal parts 


3.3.7 Interchangeability and Replaceability 


3.3.8 Workmanship 


3.3.9 Electromagnetic Interference 


3.3.10 Identification and Marking 


3.3.11 Storage 

QUALITY ASSURANCE PROVISIONS 

4.1 Phase 

I , Test/Verification 

4.1.1 

Engineering Test and Evaluation (or Development 


Test) 

4.1.2 

Preliminary Qualification Tests 

4.1.3 

Formal Qualification Tests 

i— 1 

Reliability Tests and Analyses 

4.1.5 

Engineering Critical Component QuaTi'f icatinn 

4.2 Phase 

II, Integrated Test Requirement 
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SAMPLE FORMAT "B" 


Specification No, 

Release Date 

Page 1-5 ~ 


5. PREPARATION FOR DELIVERY 

6. NOTES 

6 . 1 Supplemental Information 

6 . 2 Alternate Source Qualification 
10 . APPENDIX 
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SAMPLE FORMAT "C" 


Specification No. 

Revision No. 

Release Date 

Page II-l 

CONTRACT END ITEM DETAIL SPECIFICATION 
(PRIME EQUIPMENT) 

PART II 

PRODUCT CONFIGURATION AND ACCEPTANCE TEST 
REQUIREMENTS 

(CEI Number) 

(APPROVED NOMENCLATURE) 


Approved by: 

(Preparing Activity) 

Date 

Contract Number* 


Approved by: 

(NASA Office) 
Approval Date: 
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SAMPLE FORMAT "D” 


Specification No, 
Release Date 
Page II-2 


1. SCOPE 

This part of this specification establishes the require- 
ments for complete identification and acceptance of all units of 
(insert contract end item number and nomenclature) to be 
formally accepted by the National Aeronautics and Space 
Administration. 

1 .1 Product Configuration Baseline Acceptance 

The product configuration baseline shall be 
established by FACI of serial number (insert 
CEI serial number) . This unit and all sub- 
sequent units, regardless of intended use, 
shall be accepted to the configuration de- 
fined by serial number (insert same serial 
number) unless changes thereto have been 
formally approved by the procuring agency. 


2 . APPLICABLE DOCUMENTS 

The following documents of exact issue shown, form a part 
of this specification to the extent specified herein. In the 
event of conflict between documents referenced here and other 
detail content of Sections 3,4,5, and 10, the detail content 
of Section 3, 4, 5, and 10 shall be considered a superseding 
requirement. 

SPECIFICATIONS 

Federal 

Military 

Contractor 

STANDARDS 

Federal 

Military 

Contractor 

DRAWINGS 

BULLETINS 
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SAMPLE FORMAT "D" 


Specification No. 
Release Date 
Page 1 1- 3 ——— 


OTHER PUBLICATIONS 
Manuals 
Regulations 
Handbooks 
Etc. 

(Copies of specifications, standards, drawings, bulletins, and 
publications required by suppliers in connection with specific 
procurement functions should be obtained from the procuring 
activity or as directed by the contracting officer.) 

SECTION 3. REQUIREMENTS 

3.1 Performance 


3.2 Product Configuration 

3.2.1 Manufacturing Drawings 

The configuration of this contract end 
item shall be in accordance with (con- 
tractor's top drawing number), and 
drawings and engineering data assembled 
the re under . 

3.2.2 Government Furnished Property List 

3.2.3 Standards of Manufacturing, Manufacturing 

Processes and Production ' 

3 

SECTION 4. QUALITY ASSURANCE 

The contractor responsible for the manufacture of this CEI 
is responsible for accomplishment of each test/verification 
required herein. 

4 . 1 Product Performance and Configuration Requirements/ 
Quality Verification Cross Reference Index 

4.2. Test Verifications 


4.2.1 Drawing Compliance 

4.2.2 


4.2.3 
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Specification No. 

Release Date 

Page II-4 


4.2.4 


Etc. 


SECTION 5 , PREPARATION FOR DELIVERY 


5.1 


5.2 


Preservation and Packaging 


5.1.1 

Cleaning 


5.1.2 

Dr Y in g 


5.1.3 

Levels of Packaging 


5. 1.3.1 

Immediate Use 


5. 1.3.2 

Limited Storage 


5. 1.3. 3 

Extended Storage 


5. 1.3. 4 

Intermediate Packaging 

Packing 


5.2.1 

Domestic 

Shipment 


5. 2. 1.1 

Air 


5. 2. 1.2 

Surface 

5.2.2 

Overseas 

Shipment 


5. 2. 2.1 

Air 


5. 2. 2. 2 

Surface 


5 . 3 Shipment 
SECTION 6. NOTES 
SECTION 10. APPENDIX 

10 . 1 Acceptance Requirements for Units of the CEI 
in a Test Configuration 


10.2 Alternate Source Qualification 
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SAMPLE FORMAT "E M 


---ADDENDUM NOTICE 

This Specification has been prepared as an Addendum to: 

Specification No. 

Revision 

Release Date . 

CEI No. 

FOR 

(Approved Nomenclature) 

Used With 

(PROJECT OR SYSTEM NAME) (PROGRAM) 


This (Addendum) Specification must always be accompanied 
by the Specification (above) to which it relates. 

The exact content of Specification (insert same number as 
above) used as the basic document for this addendum is 
the revision referenced above plus the following Specifi- 
cation Change Notices to Specification (insert same number 
as above) . 
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PREPARATION OF 

CONTRACT END ITEM DETAIL SPECIFICATION 
(FACILITY) 
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PREPARATION OF 

CONTRACT END ITEM DETAIL SPECIFICATION 
(FACILITY) 


CONTENTS 

Paragraph page 

1. PURPOSE III-l 

2. SCOPE III-l 

3. APPLICABILITY III-l 

4. REFERENCE DOCUMENTS III-l 

5. EXPLANATION OF TERMS III-l 

6. PROCEDURAL REQUIREMENTS III-2 


FORMATS AND ILLUSTRATIONS 


Sample Format "A", Specification Format Title Page . . . .111-9 
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PREPARATION OF 

CONTRACT END ITEM DETAIL SPECIFICATION 
(FACILITY) 


1. PURPOSE 

This Exhibit provides NASA Apollo organizations and their 
contractors with requirements and guidance for the prepara- 
tion of the detailed specif ication for each facility contract 
end item. 

2 . SCOPE 

These instructions are applicable to the specification for 
facility end items categorized as independent facilities. 

The instructions define the content and format for each of 
two parts of the Facility Contract End Item Detail Specifica- 
tion, (FCEI Specification.) 

Part I - Facility Criteria 

Part I of the FCEI Specification is used to 
specify requirements peculiar to the design, 
development and qualification of the Facility 
Contract End Item. 

Part II - Facility Construction Contract Plans and 
Specification^ 

Part II of the FCEI Specification is used to 
specify exact configuration information 
peculiar to the contracting, construction and 
testing/quality control of the Facility Contract 
End Item. 

3. APPLICABILITY 

A Facility Contract End Item Detail Specification shall be 
prepared for each facility designated as an independent contract 
item. Instructions for the preparation of specifications for 
Direct Support-Real Property Installed Equipment (DS-RPIE) 
are included in Exhibit II. 


4. REFERENCE DOCUMENTS 

NPC-325-1 "Design Criteria and Construction 

Standards" 

5. EXPLANATION OF TERMS 
See Exhibit XVII. 
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PROCEDURAL REQUIREMENTS 

6 . 1 The Contract End Item Detail Specification (Facility) 

The FCEI Specification is composed of two parts, each of 
which has distinct and different uses in FCEI acquisition. 
Each of the two parts, when drafted to comply with these 
instructions, is complete in content and format with 
respect to its intended use. The FCEI Specification is 
controlled and accounted as an entity, using a single 
Configuration Chart and a single Specification Change 
Log, Exhibit VII. Part I, Facility Criteria, is a 
product of a Program Definition Phase or requirements 
analysis, and is the engineering instrument used to 
contract for design and development of the FCEI. Compliance 
with Part I is determined by evaluation of quality, content, 
and completeness of the facility criteria document. Part 
II of the FCEI Specification, the construction bid package 
(contract, plans and specification) , is a product of the 
design (and development, if applicable) contract. Part II 
specifies the FCEI in terms of the detailed configuration 
requirements of the facility suitable for contracting 
actual facility construction. The integrity of Part II 
must be established prior to its acceptance and/or subse- 
quent issuance by the procuring agency. Acceptance and 
issuance of Part II is dependent upon the accuracy with 
which it specifies detail configuration requirements of the 
FCEI, and the adequacy of quality of each individual unit 
of the FCEI to be produced/procured. The integrity of 
Part II is established by audit. The audit is accomplished 
by cross-comparison of the data specified in Part II, with 
the facility criteria, standard construction practices, and 
adherence to governing exhibits, regulations, and codes. 

Part II is thus established as the valid engineering instru- 
ment to be implemented contractually for direct control of 
FCEI acquisition. Compliance with the terms of Part II 
(bid package) is determined by normal construction control 
procedures of the construction agency. The title page for 
the FCEI Specification shall conform to the following 
instructions referenced directly to sample format "A": 

a. "Specification Number" - A unique identifier, within 
system, to this FCEI. (See Exhibit X.) 

b. "Revision Number" - Sequentially assigned character (s) 
to uniquely identify each revision of the specification. 

c. "Release Date” - Date formally released by the procuring 
agency. 

d. "CEI" - Contract End Item Number. (See Exhibit X.) 

e. "Approved Nomenclature" - In accordance with standard 
practice. 

f. "System Identification" - List the system or systems 
which the FCEI is designed to support. 
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g. "Approval Block" - The preparing agency and NASA 

office with engineering responsibility for the FCEI 
shall validate the specification. 

6.2 Preparation of Facility Contract End Item Detail 
Specification, Part I , Facility Criteria 

The following instructional paragraphs provide specific 
direction for the preparation of facility criteria 
documents. General deviations from the requirements of this 
exhibit require prior approval of the procuring agency or 
program office as appropriate. Facility criteria, which 
deviate from the general requirements of this exhibit, 
must cite, in an appendix, the instrument authorizing the 
deviation. The design requirements facility contract end 
item shall be specified in a facility criteria document. 

In recognition of the scope and nature of criteria required 
for given facilities, the following guide shall be used: 

6.2.1 Facility Categories . There are two general categories 
of facilities which support systems. The first is 
one which is functionally integrated with facility 
equipment. The second is the type of facility which 
is used with the system, but is functionally 
independent of the system. An integrated facility 

is one which satisfies one or more of the following 
criteria: 

a. Basic structural and architectural features are 
designed specifically to accommodate the require- 
ments unique to the system. 

b. The facility services form one or more complex 
interfaces with the system. 

NOTE: As used herein, routine power, water, air 

or steam service connections are not 
considered "complex" interfaces. 

c. The total system, including facility, forms a 
self-contained, independent entity capable of 
operation without outside supply or services for 
a specified period of time. 

A detailed and complete criteria document shall be 
accomplished for each facility categorized as an 
integrated facility. For all other system facilities, 
the criteria document shall be limited to specifica- 
tion of physical design constraints necessary to 
support general system requirements. 

6.2.2 Preparation of the Criteria Document . Part I of the 
FCEI Specification shall be prepared to comply with 
the following instructions: 

6. 2. 2.1 Section 1, "Scope" . Begin as follows: 

"This part of this specification establishes 
the requirements and basic restraints/ 
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constraints imposed upon the develop- 
ment of a design for (insert nomenclature) 
facility in support of (insert system 
nomenclature).” Subsequent sentence/ 
paragraphs shall briefly describe the 
intended purpose and general use of the 
facility with respect to the system to 
which it is related. 

6. 2. 2. 2 Section 2, "Applicable Documents" . 

Begin as follows: "The following documents , 

of the exact issue shown, form a part of 
this specification to the extend specified 
herein. In the event of conflict between 
documents referenced, and other detailed 
contents of this specification, the detailed 
requirements herein shall be considered 
superseding." List within this section 
those documents which are applicable to 
paragraphs within the body of the specifi- 
cation. Within the specification, reference 
to these documents shall be made by 
reference to their basic document number 
or other definitive designation. 

6. 2.2. 3 Section 3, "Requirements" . This section 
shall contain performance and design 
requirements for the facility. Include 

the functional requirements for the facility, 
and establish, requirements which are measures 
of the efficiency /effectiveness of the 
facility. Define the facility, identify 
critical interfaces, and specifiy design 
constraints and standards necessary to 
assure compatibility with existing or 
contemplated hardware. For integrated 
facilities, performance and design require- 
ments are allocated from, identical with, 
or in recognition of requirements established 
by the program specification. Requirements 
shall be specified in terms of the facility 
itself and not be referenced to equipment 
with which the facility must be compatible. 
The following represents an outline of 
specific information required in the FCEI 
Specification; however, it is not to be 
construed as preventing the addition of 
such information as may be required to 
properly identify the peculiar system 
facility requirements. 

6. 2.2.4 Section 3.1, "General Concept" . Describe 

in detail the use to which the facility will 
be put; describe the flow of personnel, 
material, and functions to be performed in 
the facility, including time elements, etc. ; 
identify the maintenance and logistic 
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policies to be employed; establish 
design-useful life requirements; estab- 
lish facility self-sufficiency require- 
ments, and special facility survival 
requirements . 

6. 2.2. 5 Section 3.2, "Siting and Layout" . 

a. Provide an area plan showing location 

of facility with respect to general 

area. 

b. Provide a detailed site plan showing: 

(1) Access requirements, special width 
requirements . 

(2) Required relationships between 
outside elements. 

(3) Clearances. 

(4) Parking, loading, required set- 
backs, paving, etc. 

c. Provide a floor-plan layout of the 

required facility showing: 

(1) Dimensional requirements. 

(2) Height requirements (cross section) . 

(3) Doors, widths of entrances. 

(4) Clear space requirements (no 
column intrusion allowed) . 

(5) Locate special electrical or 
mechanical provisions. 

(6) Blockouts, elevations, anchor 
bolts, or other provisions for 
equipment. 

6. 2. 2. 6 Section 3.3, "General Criteria". 


a. Civil 

(1) Axle or wheel loads on roads 

(2) Special lane width of roads. 

(3) Turn and weight provisions for 
special vehicles. 

(4) Jack loads, transfer requirements. 

(5) Parking (number of vehicles) . 
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(6) Grades on roads. 

(7) Special water and sewage 
requirements. Quantity and 
nature of water and sewage , if 
special. 

(8) Special fire protection require- 
ments (exterior) . 

(9) Fencing and security. 

(10) Location and types of existing 
utilities, if any (water, gas, 
sewer, electrical, storm drainage). 

b. Architectural 

(1) Personnel occupancy, types, 
hours per day. 

(2) Designation of use of areas within 
facility. 

(3) Types of special doors required. 

(4) Floor level requirements. Floor 
drainage. 

(5) Window requirements, if any. 

(6) Controlling dimension requirements. 

(7) Clear ceiling heights. 

(8) Exterior architectural treatment 
(concrete, masonry, brick, etc.). 
Indicate whether treatment is to 
match existing, if applicable. 

(9) Explosive safety requirements for 
construction. 

c. Structural 

(1) Crane and hoist location and loads. 
Control requirements. 

(2) Floor and roof loads. Special 
loads. Seismic loads, wind loads, 
clear interior heights. 

(3) Clear span and column-free areas. 

(4) Blast loads, shielding requirements. 

(5) Personnel ladders, elevators. 

(6) Transfer piers, dock loads. 
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(7) General configuration of building, 
number of stories. 

(8) Barricades and shielding for 
explosive blast areas. 

d. Mechanical 

(1) Interior potable water. 

(2) Environment limits. Temperature, 
humidity, ventilation . 

(3) Compressed air. 

(4) Fire protection. 

(5) Vibration and acoustical requirements. 

(6) Equipment cooling requirements. 

e. Electrical 


(1) Power requirements - type . and 
magnitude . 

(2) Light intensities. 

(3) Communications requirements. 

(4) Grounding 

f. Equipment (provide layout and list each 
piece of equipment) 

(1) Equipment name. 

(2) Units required. (number) 

(3) Purpose of equipment. 

(4) Size of equipment (governing 
dimensions, weight) . 

(5) Power requirements - heat gain, 

BTUs per hour, type cooling, in-out 
temperatures, relative humidities. 

(6) Minimum access requirements - front, 
back, sides. 


6 . 2 * 2 . 7 Section 4, "Quality Assurance Provisions 11 . 

This section shall identify special testing, 
quality control procedures, and/or performance 
verification requirements necessary to assure 
the adequacy of special or unique facility 
provisions. Standard facility verification 
requirements shall not be included herein. 
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6 . 3 Preparation of Facility Contract End Item Detail 

Specification, Part II, Facility Construction Contract 
Plans and Specifications 

This part of the FCEI Specification shall be based on Part I 
of this specification. Content, and scope of this portion 
of the specification, as well as the actual facility 
acquisition procedures and requirements, are prepared by 
architectural/engineering activities, and their type and 
format are not prescribed by this publication. 
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Approved 


Date 


SAMPLE FORMAT "A" 

Specification No. 

Revision No. 

Release Date 

CONTRACT END ITEM DETAIL SPECIFICATION 
(FACILITY) 

CRITERIA 

AND 

DESIGN 

(CEI PROJECT NUMBER) 

(APPROVED NOMENCLATURE) 

FOR 

(SYSTEM NAME ) (SYSTEM) 


By 

(Preparing Activity) 


Approved By 

(Apollo Program 
Office or 
equivalent) 


Date 
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PREPARATION OF CONTRACT END ITEM 
DETAIL SPECIFICATION 
(IDENTIFICATION ITEM) 
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PREPARATION OF CONTRACT END ITEM 
DETAIL SPECIFICATION 
(IDENTIFICATION ITEM) 


CONTENTS 

Paragraph Page 

1. PURPOSE IV-1 

2. SCOPE IV-1 

3. APPLICABILITY IV-1 
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PREPARATION OF 

CONTRACT END ITEM DETAIL SPECIFICATION 
(IDENTIFICATION ITEM) 


1. PURPOSE 

This Exhibit provides NASA Apollo organizations and contractors 
with requirements and guidance for the preparation of a contract 
end item (CEI) detail specification for an item of equipment 
categorized as an "Identification Item". 

2 . SCOPE 

These instructions define the content and format for a CEI 
specification for a contract end item categorized as an "Identi- 
fication Item" . 

3 . APPLICABILITY 

An "Identification Item" is one which satisfies the following 
criteria: 

a. It can be qualified by inspection and/or simple 
demonstration . 

b. Once in manufacturing , quality control at manufacturing 
level can be the basis for verification of quality , 

and acceptance can be based on verification that the 
item, as fabricated and assembled, conforms to the 
drawings. Acceptance testing to verify performance 
will not be specified. 

c. Because of its use, relationship to other end items, 
and simplicity of function and design, few, if any, 
design changes are anticipated once the product config- 
uration baseline for the item is established. 

4 . REFERENCE DOCUMENTS 

DSM 4120. 3-M 1 April 1966 "Standardization Policies, 

Procedures and Instructions" 

NHB 5300-4 (IB) April 1969 "Quality Provisions for Aero- 

nautical and Space System 
Contractors" 

NHB 8080.1 May 1964 "Apollo Test Requirements" 

NPC 200-3 April 1962 "Inspection Systems Provisions 

for Suppliers of Space Mater- 
ials, Parts, Components and 
Services" 

NPC 250-1 30 July 1963 "Reliability Program Provisions 

for Space System Contractors" 
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5. EXPLANATION OF TERMS 
See Exhibit XVII. 

6 . PROCEDURAL REQUIREMENTS 

Examples of end items specified in this type of specification 
are handling equipment , special tools, adapters, brackets, 
mounting fixtures, dollies, work stands, reuseable containers, 
off-the-shelf commercial items with minor contractor modifica- 
tions, etc. 

NOTE: A number of closely related items may be assembled 

and controlled as piece-parts under a single draw- 
ing and part number as a kit, if they are related 
functionally, and will be allocated as a unit for 
initially equipping the using agency. Under these 
circumstances, the "kit" requires only a single 
identification specification . 

The format of this specification is based on the premise that 
the requirements specification is a brief, concise document, 
and that few changes will be required; hence, it is more econom- 
ical to reissue the complete specification with a specification 
change log that permits changes to individual parts of the doc- 
ument on an "add” and "delete" basis and permits use of the 
configuration chart as the only means of recording changes to the 
specification. (See Exhibit VII for specification maintenance 
instructions.) All CEI specifications are prepared in two dis- 
tinct parts: Part I specifies performance/design and qualifica- 

tion requirements. Part II specifies product configuration, 
quality assurance and preparation for delivery requirements. 

For a detailed definition of the nature and use of each of the 
two parts of a CEI specification, see Exhibit II, paragraph 6. 

The following instructional paragraphs are numbered or otherwise 
identified to refer directly to sample format "A". 

Specification Title Data 

The title of the specification shall be "Contract End Item 
Detail Specification (Identification Item) Performance/ 
Design/Product Configuration Requirements" and shall in- 
clude the following: 

"Approved Nomenclature" 

"Project/System Name" List the project (s) or sys- 

tems (s) which the CEI is de- 
signed to support. For CEI 1 s 
which cannot be identified 
with a project (s) or systems (s), 
e.g., equipment storage cabinets, 
enter the phrase "Not Project (s) 
or System (s) Equipment". 
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Specification Identification and Authentication Data 

Specification identification and authentication data shall 
include the following: 


"Specification Number" An identifier, unique, within 

a project or system, to this 
CEI . (See Exhibit X.) 

"Revision" Sequentially assigned character (s) 

to uniquely identify each revision 
of the specification number and 
revision identification which may 
be composed of alphabetic and/or 
numeric characters, or both. 

(See Exhibit X.) 


"Release Date" 


"CEI Number" 


Date formally released by the 
preparing activity . 

Contract End Item Number. 

(See Exhibit X.) 


"Approval Block" The preparing activity (contractor 

or Government organization pre- 
paring the specification) shall 
formally approve the specification. 
The procuring agency (Apollo Pro- 
ject Office or equivalent) shall 
formally approve the specification. 


6 . 1 Instructions for the Preparation of Part I, "Performance/ 
Design and Qualification Requirements ~~~ 

The following instructions are applicable to the preparation 
of Part I of the specification: 


6.1.1 Section 1, "Scope" This section of the specification 
shall begin with opening sentence/paragraph as shown 
in sample format "A" . A subsequent sentence/para- 
graph, as indicated be sample format "A", shall briefly 
describe the intended general use of the CEI. 

6.1.2 Section 2, "Applicable Documents" This section of the 
CEI specification shall begin with the opening sentence/ 
paragraph contained in sample format "A". List those 
documents (specifications, standards, drawings, 
bulletins, manuals, etc.) which are applicable to 
paragraphs within the body of this part of the speci- 
fication (Sections 3 and 4 of Part I) . Within the 

body of the specification, reference to these documents 
shall be made by reference to their basic document num- 
ber or other definitive designation. Refer to Defense 
Standardization Manual 4120. 3-M for further instruc- 
tions on listing of applicable documents. 
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6.1.3 Section 3 , 11 Requirements " Performance/design require- 
ments shall be specified to the level of detail neces- 
sary to establish the use of the CEI in support of 
other projects, systems or equipment and facilities, 
and to establish that the requirement is unique and 
cannot be satisfied from existing NASA inventory. 
Requirements shall be specified quantitatively in terms 
of measurable physical properties with tolerances. 
Government furnished property to be incorporated in 
the design of the CEI shall also be specified. For 
CEI * s which support projects or systems, incorporate 
either directly or by reference the engineering pro- 
duct of analysis record generated as a product of 
analysis . 

6.1.4 Section 4 , "Quality Assurance” This section shall 
include applicable content of "Apollo Test Require- 
ments", NHB 8080.1? NASA Quality Assurance Publicat- 
ion NHB 5300.4 (IB) and NPC 200-3; and NASA Reliability 
Publication NPC 250-1. Specify the demonstrations/ 
verifications necessary to establish that the item, 

as designed and developed, satisfies each requirement 
established in Section 3 of Part I. Accomplishment 
of the verifications shall constitute qualification 
of the CEI. For identification items, qualification 
is limited to inspection and simple demonstrations. 
Requirements shall be specified to the level of de- 
tail necessary to clearly establish the validity and 
accuracy of the verification method. 

6.1.5 Section 5, "Preparation for Delivery" This section is 
not applicable to Part I of a CEI specification. See 
Exhibit II, paragraph 6. 

6 . 2 Instructions for the Preparation of Part II "Product Con- 
figuration and Qualification Assurance Requirements " 

The following instructions are applicable to the preparation 

of Part II of the specification. (See Sample Format "B".) 

6.2.1 Section 1, "Scope" Begin with the opening sentence/ 
paragraph contained in sample format "B" . Descrip- 
tive material identifying the relationship of this 
CEI to other projects of systems equipment may be 
included . 

6.2.2 Section 2, "Applicable Documents" Begin with the 
opening sentence/paragraph contained in sample format 
"B" . The general instructions for Section 2 of Part I 
are applicable, with the exception that this section 
references only documents which are applicable to 
Sections 3, 4, and 5 of Part II. 

6.2.3 Section 3, "Requirements" Begin with the opening 
sentence/paragraph contained in sample format "B". 
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Normally, for identification items, this section 
should be limited to a requirement to comply with 
the drawing. Standards of manufacture, manufacturing 
processes and production which must be verified at 
time and place of delivery to establish the quality 
of the CEI , shall be specified. All requirements 
shall be specified at environmental conditions normal 
to the place of acceptance, and shall not attempt to 
simulate the environment in which the CEI shall be 
used. Requirements shall be specified in physically 
measureable quantitative terms, with tolerances, in 
terms of the CEI itself, and without direct reference 
to equipments or facilities with which the CEI must 
be compatible. Requirements shall be specified to 
the level of detail necessary to establish limits 
for the verifications to be specified in Section 4 
of Part II. 

6.2.4 Section 4, "Quality Assurance 11 This section shall 
include applicable content of "Apollo Test Require- 
ments", NHB- 8080.1; NASA Quality Assurance Publication 
NHB 5300. 4 (IB) and NPC 200-3; and NASA Reliability 
Publication NPC 250-1. The method of confirming 

that the CEI, as fabricated and assembled, complies 
with the production drawings and the verification/ 
demonstrations necessary to assure that the CEI, as 
manufactured and assembled, satisfies the require- 
ments of Section 3 of Part II shall be specified. 

Each demonstration/verification shall be specified to 
the level of detail necessary to establish the va- 
lidity and accuracy of the verification method, and 
present a clear, nonsub jective determination of the 
quality of the CEI. 

6.2.5 Section 5, "Preparation for Delivery" This section 
shall specify requirements for preservation, pack- 
aging, packing, and marking or otherwise preparing 
the CEI for shipment. To the. extent practical this 
shall be accomplished by referencing established 
standards. Where established standards are inade- 
quate, see Exhibit II, Part II, paragraph "Section 5, 
Preparation for Delivery". 

6.2.6 Section 6, "Notes" This section of the specification 
shall include information of particular importance to 
the procuring agency, i.e., ordering information for 
technical data. 

6.2.7 Section 10, "Appendix" This section of the CEI spec- 
ification shall include requirements of limited appli- 
cability, such acceptance of the CEI in an instru- 
mented configuration. See Exhibit II, Part II, para- 
graph "Section 10, Appendix". 
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SAMPLE FORMAT "A" 

CONTRACT END ITEM DETAILED SPECIFICATION 
(IDENTIFICATION ITEM) 

PERFORMANCE/DESIGN/PRODUCT CONFIGURATION REQUIREMENTS 
(APPROVED NOMENCLATURE) 
for 

Project or System Name Project or System 

Spec. No. 

Revision 

Release Date 

CEI No. 

Approved (Preparing Agency) 

Contract Number 

Approved (Procuring Agency) 

Part I "Performance/Design and Qualification Requirements" 

1. Scope 

This part of this specification establishes performance/design 
requirements for one type-model-series of an equipment identified 

as (insert nomenclature . This contract end 

item (provides) (accomplishes) . 

2. Applicable Documents 

The following documents of exact issue shown form a part of this 
part of this specification to the extent specified herein. 

3. Requirements 

4. Quality Assurance 
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SAMPLE FORMAT "B" 

Part II , "Product Configuration and Quality Assurance Requirements" 

1. Scope 

This part of this specification establishes the product configuration 
requirements for one type-model- series of equipment identified as 
( insert nomenclature) - 

2. Applicable Documents 

The following documents of exact issue shown form a part of this 
specification to the extent specified herein. 

3. Requirements 

The configuration of this contract end item shall be in accordance 
with contractor's top drawing number and drawing and engineering 
data assembled thereunder. 

4. Quality Assurance 

5. Preparation for Delivery 

6 . Notes 
10. Appendix 

10.1 Acceptance of CEI in an Instrumented Conf igura.tion . 
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PREPARATION OF 

CONTRACT END ITEM DETAIL SPECIFICATION 
(REQUIREMENT ITEMS) 
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PREPARATION OF 

CONTRACT END ITEM DETAIL SPECIFICATION 
(REQUIREMENT ITEMS) 


CONTENTS 

Paragraph Page 

1. PURPOSE V-l 

2. SCOPE V-l 

3. APPLICABILITY V-l 

4. REFERENCE DOCUMENTS V-l 

5. EXPLANATION OF TERMS V-2 

6. PROCEDURAL REQUIREMENTS V-2 

FORMATS AND ILLUSTRATIONS 

Sample Format "A", Specification Format 

Title Page V-8 

Sample Format "B", Specification Format Outline. V-9 

Sample Format "C", Specification Format Outline. V-ll 
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PREPARATION OF 

CONTRACT END ITEM DETAIL SPECIFICATION 
(REQUIREMENT ITEMS) 


1. PURPOSE 

This Exhibit provides NASA Apollo organizations and 
contractors with requirements and guidance for the 
preparation of a Contract End Item (CEI) detail speci- 
fication for items of equipment categorized as "Require- 
ment Items." 

2. SCOPE 

These instructions define the content and format for 
the CEI specification for contract end items categorized 
as "Requirement Items." 

3. APPLICABILITY 

A "Requirement Item" is one which satisfies the follow- 
ing criteria: 

a. It has been developed. 

b. It is an item which is Government Furnished 
Equipment (GFE) . 

c. It is necessary to support an item or items 
being developed, either to be used with, or 
to be assembled into, the item(s) being 
developed. 

4. REFERENCE DOCUMENTS 

The following documents are to be considered as refer- 
ence material for the purpose of interpreting the 
requirements of this exhibit but do not form a part of 
this exhibit: 
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AFM 67-1 
(or NASA equi- 
valent) 


" US AF Supply Manual, Volume I, 
Part II, Chapter II." 

DSM 

4120. 3-M 

1 April 
1966 

"Standardization Policies, 
Procedures and Instructions" 

H-2- 

-1 


"Cataloguing Handbook , Federal 
Supply Classification, Part I, 
Groups and Classes." 

NHB 

(IB) 

5300-4 

April 

1969 

"Quality Provisions for Aero- 
nautical and Space System 
Contractors" 

NHB 

8080.1 

May 1964 

"Apollo Test Requirements" 

NPC 

200-3 

April 

1962 

"Inspection Systems Provisions 
for Suppliers of Space Mater- 
ials, Parts, Components and 
Services . " 

NPC 

250-1 

30 July 
1963 

"Reliability Program Provisions 
for Space System Contractors" 


5 . EXPLANATION OF TERMS 
See Exhibit XVII 

6. PROCEDURAL REQUIREMENTS 

The requirements specification is a single document 
which specifies the items of equipment existing in 
inventory (see paragraph 3b) necessary to support 
or to be installed in the contract end items being 
designed/developed by a single contractor. 

NOTE: Contract end items in development which 

must, during the progress of development, 
be transferred among contractors, are not 
to be classified as "in inventory" or 
carried in a requirement specification. 

One requirements specification shall be prepared by 
each contractor responsible for development of contract 
end items, and shall include all inventory items necessary 
to support the end items in development. 
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6.1 Instructions for Preparation of a Requirements 
Specification 

The format for the requirements specification title 
page shall be in accordance with Sample Format "A". 
The following instructional paragraphs are numbered 
or otherwise identified to refer directly to 
Sample Format "B“: 

6.1.1 Section 1 "Scope” Begin with the opening 
sentence/paragraph as shown in sample format 
"B" . A brief, descriptive entry shall be 
included which establishes the relationship 
of the required item(s) to the contract end 
item(s) and the project or system with which 
they will be used. A sample entry might 
read: ” . . . . support the guidance system 
of the spacecraft.” 

6.1.2 Section 2 “Applicable Documents” Begin with 
the opening sentence/paragraph as shown in 
sample format "b" . Due to the nature and 
use of this specification, reference to 
individual specifications and documents cited 
in the body of the specification, peculiar 

to individual items of equipment, shall not 
be redundantly included. 

6.1.3 Section 3 “Requirements” Begin with the 
opening sentence/paragraph as shown in 
sample format "B". Each subparagraph shall 
identify one requirement item which is 
specified in detail in an individual 
appendix to this specification. Each 
subparagraph shall include the following: 

a. Subparagraph number. (Used as the basic 
reference to each single appendix.) 

b. Federal Stock Class Code. (Refer to 
H-2-1 Cataloguing Handbook Federal 
Supply Classification, Part I-Groups 
and Classes : and AFM 67-1, USAF Supply 
Manual , Volume I-Part II-Chapter II; or 
NASA equivalent.) 

c. Part number. 
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d. Nomenclature. 

e. Number of the contract end item into which 
the requirement item installs. 

NOTE: For those items which are used 

" as delivered" from the inventory 
as an end item, and which are not 
installed in other project or system/ 
equipment, enter the words "Not 
Applicable. " 

For ease in specification maintenance, no particular 
sequence, other than subparagraph number, shall be 
established for entries in Section 3. Items shall be 
added to the end of the list at the time it is 
determined that the item shall be supplied from in- 
ventory. If an item is cancelled, the paragraph num- 
ber shall not be used to reidentify a new item. The 
word "cancelled" and the date of cancellation shall 
be typed in the "paragraph" column in lieu of the 
paragraph number for the cancelled item, and the 
respective appendix removed from the specification. 
Instructions for the preparation and content of the 
appendices are included herein. The Federal stock 
class code, where applicable, and the nomenclature 
for a cancelled item, shall be printed in their respec- 
tive columns. Three months after cancellation, the 
Federal stock class code and nomenclature data for a 
cancelled item may be removed from the specification; 
however, the particular paragraph number of a cancelled 
item shall not be reused to reidentify another item, 
and the word "cancelled" and the date of cancellation 
shall continue to be printed in the "paragraph" column 
in all succeeding revisions to the specification. 

6.1.4 Section 4 "Quality Assurance" Include applicable content 
of "Apollo Test Requirements", NHB 8080.1; NASA Quality 
Publications NHB 5300,4 (IB) and NPC 200-3; and NASA Relia- 
bility Publication NPC 250-1. Quality assurance require- 
ments for items of equipment shall include necessary 
requalification to a new use, environment, or uprated 
performance requirement. Requirements for requalification 
shall be specified for each item in the individual 
appendix specifying the item. Quality assurance require- 
ments shall include receiving "bench checks" of the 
requirement item to be accomplished by the contractor 
preparing the requirement specification. If these 
"bench checks" are complex, they require close coordina- 
tion with the manufacturer of the item. 

6.1.5 Section 5 "Preparation for Delivery" Requirements basic 
to preparing each item specified herein for delivery 
shall be included in the respective appendix which 
specifies the item. 

6.1.6 Section 6 "Notes" Administrative information of impor- 
tance to the procuring agency in the use of this 
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specification may be included herein, e.g., 
identification of manufacturer of individual items 
specified which are complex and will require the 
coordinated effort of the original manufacturer and 
the contractor preparing the requirement specification 
to develop valid receiving tests or verifications for 
the item. 

6.1.7 Section 10 “Appendix” The requirement specification 

shall include an individual appendix for each require- 
ment item. Each appendix shall conform to the format 
illustrated in sample format "B" and comply with the 
following instructions which are numbered or other- 
wise identified to refer directly to sample format "B". 

6.1.7. 1 " Appendix” Enter the subparagraph number of 
the paragraph in Section 3 which identifies 
the item. 

6.1. 7. 2 "Federal Stock Class Code" Enter the Federal 
stock class code included in the respective 
subparagraph of Section 3. 

6.1.7. 3 Section 1 "Scope" Include the opening 
sentence/paragraph shown in sample format 
"B". Subsequent information of a general 
or descriptive nature may be included. 

6 . 1 . 7 . 4 Section 2 "Applicable Documents" The 
reference to the document used as a basis 
for identifying the particular inventory 
item specified in this appendix shall be 
included e.g., technical information file, 
government specification, manufacturers' 
specification, technical manual, etc. 

6.1. 7. 5 Section 3 "Requirements" Specify the 
performance/design requirements which the 
item must satisfy. Requirements shall be 
limited to those necessary to establish 
project or system compatibility, and to 
establish the physical/functional interface 
relationship of the item to other project 
system/equipments facilities . Requirements 
shall be specified to a level of detail 
necessary to permit the NASA end item manager 
to select alternate items to the one 
specifically identified above, to satisfy 
this requirement. Descriptive material which 
outlines the use of the item in the project 

or system shall be included. All performance/ 
design requirements shall be stated in 
physically measurable terms, with tolerances. 
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in terms of the item itself and not by 
relating it to equipment/facilities with 
which it must be compatible. To the 
extent applicable, the product of 
functional analysis, or similar record 
generated as a product of "systems 
engineering," may be incorporated. 

6.1. 7.6 Section 4 "Quality Assurance" Include 
applicable content of "Apollo Test Require- 
ments," NHB 8080.1; NASA Quality Assurance 
Publications NHB 5300.4 (IB) and NPC 200-3; and 
NASA Reliability Publication NPC 250-1. 

Specify, in subparagraphs , requirements for 
requalification of the item of equipment to 

a new use of environment, and/or specification 
of receiving tests/verifications to be 
accomplished by the contractor receiving the 
inventory item for installation into program 
equipment. 

6. 1.7. 7 Paragraph 4.1 "Requalification" When applicable, 
specify the requirements and methods for 
accomplishing requalification of the item to 

a new use or environment. Tests/verifications 
shall be specified to the level of detail 
necessary to establish the scope and accuracy 
of the test method. Formal test/verifications 
shall not incorporate, either directly or by 
reference, detail test planning documentation 
and operating instructions. Requirements shall 
be the basis for preparation and validation 
of such documents. 

NOTE: No entry shall be made in this 

paragraph until the exact item 
to be used to satisfy the 
requirement has been selected and 
the related technical data 
reviewed. 

6. 1.7. 8 Paragraph 4.2 "Receiving Tests" Specify 
requirements for tests/verifications to be 
accomplished by the receiving contractor 
prior to installation of the item into a 
contract end item. Reference technical 
manuals, specifications or other technical 
data to be supplied by NASA which specifies 
such tests, or which shall be the basis for 
preparation of a test/verification specifi- 
cation by the receiving contractor. Tests/ 
verifications shall be specified in physically 
measurable terms, with tolerances, in terms 
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of the item itself and without direct 
reference to detail methods for accomplishing 
the test. Tests/verifications shall be 
specified to the level of detail necessary 
to clearly establish the validity and accuracy 
of the test method and permit a clear, non- 
subjective determination of the quality of 
the item. 

6.1. 7.9 Section 5 Preparation for Delivery" This 
paragraph shall be limited to descriptive 
information to assist NASA in determining 
the nature of packing and packaging require- 
ments for the item for shipment to the 
contractor. It shall include anticipated 
length of storage prior to use, storage 
environment, etc. 
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SAMPLE FORMAT "A" 


Specification No. 

Revision No. 

Release Date 

CONTRACT END ITEM DETAIL SPECIFICATION 
(REQUIREMENT ITEMS) 

PE RFO RMAN CE /DE S I GN 
AND 

PRODUCT CONFIGURATION 
REQUIREMENTS 
(CEI NUMBER) 

(APPROVED NOMENCLATURE) 

FOR 

(PROJECT OR SYSTEM NAME) (PROJECT OR SYSTEM) 

Approved By Approved By 

(Preparing Activity) (NASA Office) 


Date 


Date 


Contract Number 
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SAMPLE FORMAT "B" 

1. SCOPE 

The items of equipment specified herein must be supplied from 
NASA inventory to support . 

2. APPLICABLE DOCUMENTS 

Because of the nature and use of this specification, references 
to documents applicable to each particular item of equipment 
are stated in the paragraph which specifies the item of equip- 
ment and are not redundantly recorded herein. 

3. REQUIREMENT 

Each of the following subparagraphs reference an appendix which 

identifies an end item of equipment to be supplied from NASA 

inventory. In the appendix, features and characteristics are 

specified for each end item of equipment which must be satisfied 

to assure compatibility of performance and design of the item 

with project or system requirements. 

Federal The CEI Into 

Subparagraph Stock Class Part Which It 

No. (Appendix) Code Number Nomenclature Installs 

3.1 

3.2 

3.3 

4. QUALITY ASSURANCE 

Requirements for quality assurance for items included herein are 
specified in their respective appendix in Section 10, "Appendices." 
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5. PREPARATION FOR DELIVERY 

Requirements for preparation for delivery of each item specified 
herein are included in the individual appendix which specifies 
the item in detail. 


6 . NOTES 
10. APPENDIX 
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SAMPLE FORMAT "C" 

Appendix Federal Stock Class Code 

1. SCOPE 

This appendix establishes the requirement for one item of 
equipment from NASA inventory identified as (insert 
nomenclature and type-model-series, and other identifying 
data,) for the (insert/project or system nomenclature.) 

2. APPLICABLE DOCUMENTS 

3. REQUIREMENTS 

4 . QUALI TY AS S URAN CE 

4.1 Requalification 

4. 2 Receiving Tests 

5. PREPARATION FOR DELIVERY 
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PREPARATION OF DETAIL SPECIFICATION 
(CRITICAL COMPONENTS) 
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PREPARATION OF DETAIL SPECIFICATION 
(CRITICAL COMPONENTS) 


CONTENTS 

Paragraph Page 

1. PURPOSE VI- 1 

2. SCOPE VI -1 

3. APPLICABILITY Vl-rJ. 

4. REFERENCE DOCUMENTS VI-1 

5. EXPLANATION OF TERMS VI-1 

6. PROCEDURAL REQUIREMENTS VI-1 

FORMATS AND ILLUSTRATIONS 

Sample Format "A", Enginqering Critical Component 

Specification Title Page VI-6 
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PREPARATION OF 
DETAIL SPECIFICATIONS 
(CRITICAL COMPONENTS) 


1. PURPOSE 

This Exhibit provides NASA Apollo organizations and contractors 
with requirements and guidance for the preparation of detail 
specifications for critical components which are part of a contract 
end item. 

2 . SCOPE 

Administrative and specification requirements are established for 
the preparation of detail specifications for components which have 
been identified in a contract end item detail specification as: 

a. Engineering critical components 

b. Logistic critical components 

Critical component detail specifications, with the contract end 
item detail specification to which they apply, shall fully define 
all qualification requirements for the contract end item (CEI) . 

3. APPLICABILITY 

Applies to all critical component specifications which are 
incorporated by reference in a contract end item (CEI) detail 
specification (refer to Exhibits II and III) , and which are to be 
approved by the procuring agency at the time the CEI has been 
qualified . 

4 . REFERENCE DOCUMENTS 

The following documents of the exact issue shown, or part thereof 
as further described, form a part of this exhibit: 

Exhibit II 
Exhibit III 


5. EXPLANATION OF TERMS 
See Exhibit XVII. 

6 . PROCEDURAL REQUIREMENTS 

6 . 1 General Requirements 

NASA shall normally state the complete requirements for design 
and manufacture of a contract end item in a contract end item 


"Preparation of Contract End Item Detail 
Specification (Prime Equipment)." 

"Preparation of Contract End Item Detail 
Specification (Facility) ." 
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detail specification. Normally, the CEI, and all of its parts, 
will be qualified as an entity, and the engineering data and 
qualification test results submitted in accordance with the CEI 
specification will fully provide the logistic and reprocurement 
requirements. In preparing a CEI specification for large and 
complex equipment, the contractor, or procuring agency, will 
list therein, certain components of the CEI to be individually 
specified and qualified as engineering or logistic critical 
components. Components so listed in an approved CEI specifica- 
tion shall be specified and processed in accordance with this 
exhibit. 

6.1.1 Engineering Critical Component Selection The contractor 
in conjunction with NASA, shall designate components of 
a CEI as engineering critical components when one or 
more of the following applies: 

a. Qualification of the component will suffice to 
qualify the entire CEI. 

b. Reliability of the component is critical, i.e., it 
will jeopardize crew safety, mission success or sig- 
nificantly affect the ability of the CEI to perform 
its overall function. 

c. Technical complexity and/or producibility of the 
component is sufficiently critical to warrant an 
individual specification. 

d. The CEI cannot be adequately qualified except by 
separately qualifying the component. 

The contractor shall list all engineering critical com- 
ponents in Part I of the CEI specification (see Exhibits 
II and III) . Once Part I of the CEI has been formally 
approved, the contractor shall add or delete critical 
components therein by submitting a design requirements 
ECP . (See Exhibit IX.) The contractor shall proceed in 
accordance with this exhibit when the CEI specification 
or ECP is approved. 

6.1.2 Logistics Critical Component Selection The contractor, 
in conjunction with NASA, shall designate components 
of a CEI as logistics . critical components when one or 
more of the following applies: 

a. The component is an item for which the provisioning 
of spares or selection of spares is required. 

b. The component has been identified for multiple 
source procurement, by NASA. 

The contractor, in conjunction with NASA, shall list 
all logistic critical components in Part I of the 
CEI specification. Once Part I of the CEI has been for- 
mally approved, the contractor shall add or delete cri- 
tical components therein by submitting a design require- 
ments ECP. (See Exhibit IX.) The contractor shall pro- 
ceed in accordance with this exhibit when the CEI 
specification or ECP is approved. 


VI-2 



EXHIBIT VI 


6 - 2 Preparation of Engineering Critical Component Specifications 

The contractor shall prepare these detail specifications 
in accordance with the format and instructions contained in 
Exhibit II and as modified in the following subparagraphs. 
Specifications for engineering critical components shall 
contain both a Part I and Part II. 


6.2.1 Specification Part I, Section 3, " Requirements" 

The contractor shall, to the maximum extent practical, 
abbreviate the detailed content of this section. 
Applicable paragraphs in the parent specification for 
the CEI, of which the component is a part, shall be 
incorporated by reference. All requirements in the 
component specification shall be compatible with the 
requirements in the CEI specification. 

6. 2. 1.1 Paragraph 3.2 in Exhibit II shall not be used 
in the preparation of component 
specifications . 


6.2.2 Specification Part I, Section 4, "Quality Assurance 
Provisions" Quality assurance provisions shailbe 
limited to the following requirements: 


6. 2. 2.1 The qualification testing required for the 
component shall be completely specified. 

(See Exhibit II, Section 4, Quality Assurance 
provisions, and paragraph 4.1.3, "Formal 
Qualification Test.") 


6. 2. 2. 2 The reliability testing and analysis, to the 
extent required for the component, shall be 
specified. (See Exhibit II, Section 4, 
Quality Assurance Provisions, and 4.1.4, 
"Reliability Tests and Analyses".) 


6.2.3 Specification Part II, "Product Configuration and 
Acceptance Test Requirements" The contractor shall 
prepare Part II of critical component specifications 
in accordance with the format and instructions contained 
in Exhibit II and as modified in the following 
subparagraphs . 


6. 2. 3.1 The contractor shall complete only those 

subparagraphs in Part II which are essential 
for reprocurement of the item from another 
source (e.g., production control and acceptance 
testing requirements) . 


6.2. 3.2 Subparagraphs which are not essential for 
reprocurement shall be entered with the 
notation "not applicable" or "N/A. " 
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6.2. 3. 3 The requirements for Part II shall be 

mutually established with the procuring 
agency at the time the critical component 
is provisioned (i.e., provisioned by 
either the contractor or procuring agency, 
whoever has the logistic support responsi- 
bility) . 

6.2.4 Engineering Critical Component Specification Title 

Page , The title page for engineering critical component 
specifications shall be prepared in accordance with 
sample format "A" of this exhibit. The specification 
document and the critical component specified shall 
be identified by standard configuration identification 
numbers (refer to Exhibit X) . 

6. 2. 4.1 The specification identification number of 
the design activity shall be entered as 
shown. It shall include the latest revision 
letter assigned by the contractor at the 
time of initial submittal for formal approval 
by the procuring agency. 

6. 2. 4.2 The code identification number of the design 
activity shall be entered as shown. 

6.2.4. 3 The permanent drawing number (which is, or is 
included in, the part number for the critical 
component) and nomenclature for the critical 
component, as assigned by the design activity, 
shall be entered as shown. 

6. 2. 4.4 The signatures of the authorized personnel 
who approved the specification at the time 
of initial formal approval by the procuring 
agency, shall be the only signatures entered. 

6 . 3 Preparation of Logistic Critical Component Specifications 

Specifications for logistic critical components shall be 
prepared in accordance with the format for Part II, "Product 
Configuration and Acceptance Test Requirements," only, as 
described in Exhibit II. 

6 . 4 Administrative Requirements 

Critical components shall be managed at contract end item 
levels of control and as stated in the subparagraphs below. 

6.4.1 Specifications and Engineering Drawings. Critical 

component specifications shall be prepared and main- 
tained by the contractor and shall be approved by the 
procuring agency. Engineering drawings for critical 
components shall always be prepared and controlled as 
part of the drawing "trees" for the CEI of which the 
component is a part. 
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6. 4. 1.1 The specification shall be presented for 
preliminary approval at the request of 
the procuring agency and submitted for 
final approval at the completion of 
qualification testing of the component. 

6. 4. 1.2 Qualification testing shall be certified 

as complete on the title page of the speci- 
fication by the contractor or by the 
procuring agency as directed by the Center 
program office. 

6.4.1. 3 Specification approval and certification 
shall constitute completion of qualification 
testing, unless further authorized by ECP . 

6. 4.1.4 Drawings, or data other than the specif ication , 
shall be submitted for critical components 
unless otherwise specified by contract. 

6.4.2 Qualification Testing. Qualification of critical 
components shall be accomplished as part of the 
qualification program for the CEI of which they are 
a part. 

6. 4.2.1 Test schedules shall be planned for completion 
prior to acceptance of the first CEI to be 
delivered for the intended use of type-model- 
series. Normally, this will be at the time 

of FACI for the CEI. 

6. 4.2.2 Test data shall be subject to review and 
surveillance by the local representative of 
the procuring agency. 

6.4.2. 3 Test data and other reports shall be prepared 
for submittal unless otherwise specified by 
the procuring agency. 
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SAMPLE FORMAT "A" 


Specification No. 
Code Identification No. 


ENGINEERING CRITICAL COMPONENT SPECIFICATION 

PART I 

PERFORMANCE/DESIGN AND 
QUALIFICATION REQUIREMENTS 

and 

PART II 

PRODUCT CONFIGURATION AND 
ACCEPTANCE TEST REQUIREMENTS 

for 

(Permanent Drawing Number and Nomenclature) 


Approved by: 

(Designee) 

(Design Activity Contractor's 
Name) 


Approved by; 

(Designee) 
(Procuring Agency's Name) 
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SPECIFICATION MAINTENANCE 


1. PURPOSE 


This Exhibit provides NASA Apollo organizations and contractors 
with requirements and guidance for the preparation of Specifica- 
tion Change Notices, and for the formal recording of changes to 
all specifications discussed in Exhibits I through VI. 

2 . SCOPE 

These instructions define the format and content for the following 
documents, which pertain to the preparation of Specification 
Change Notices, and for the approval, control, format, and record- 
ing thereof . 

a. Specification Change Notice Sample Format "A" 

Note: Where using agencies exercise the option of Paragraph 1. 

Policy (page 1 of this document) Specification Change 
Notices shall be prepared and used as specified by the 
"Changes and Revisions" requirements of MIL-STD-490. 

b. Specification Change Log Sample Format "B" 

c. Specification Configuration Chart Sample Format "C" 

d. Specification Identification Index Sample Format "D" 

3. APPLICABILITY 


Contractors to NASA are responsible for the compliance of their 
subcontractors, vendors and suppliers. 

4 . REFERENCE DOCUMENTS 


The following exhibits of this document shall be considered as 
reference material for the purpose of interpreting the require- 
ments of this exhibit, but do not form a part of this exhibit: 


Exhibit I 


Exhibit II 
Exhibit III 
Exhibit IV 


"Preparation of Program, Project and 
System Performance and Design Requirements 
Specification " 

"Preparation of Contract End Item Detail 
Specification (Prime Equipment) " 

"Preparation of Contract End Item Detail 
Specification (Facility) " 

"Preparation of Contract End Item Detail 
Specification (Identification Item) " 


VII-1 



EXHIBIT VII 


Exhibit V "Preparation of Contract End Item 

Detail Specification (Requirement Items) " 

Exhibit VI "Preparation of Detail Specification 

(Critical Components) " 


Exhibit IX "Preparation of Engineering Change Proposals 

for Contract End Items." 

5. EXPLANATION OF TERMS 
See Exhibit XVII 

6. PROCEDURAL REQUIREMENTS 

The preparation and formal recording of specification change 
notices shall be accomplished as required by this exhibit. 

The following instruments are used to formally transmit 
and/or record changes to approved specifications, and shall 
be prepared to comply with the following instructions re- 
ferenced to the formats attached: 

6 . 1 Specification Change Notice (SCN) 

The specification change notice is used to record 
exact changes to all approved specifications. Each 
ECP which changes the established baseline shall note 
the effect of the change on specifications and shall 
have an SCN enclosed with it. The SCN shall, when 
submitted for approval, reflect the change to the 
specification that will result if the ECP is approved. 

By definition, all Class I engineering changes require an 
SCN and vice versa . SCN ' s will not be distributed to 
other activities on the specification distribution list 
until the SCN has been approved by the procuring agency. 
Errata changes of a minor nature that correct typographical 
errors, punctuation, etc., shall be collected and sub- 
mitted with the next technically required ECP and 
accompanying SCN. Errors in specified dimensions, 
parameters, tolerance, etc, shall not be classed as 
errata changes, and shall require formal approval of 
the procuring activity. Each SCN to a specification 
shall be inserted in front of the page it modifies. 

6.1.1 Preparation of the SCN. The SCN format is 
illustrated in sample format "A" . The in- 
structions for completing the SCN are as 
follows : 


6. 1.1.1 Block Completion. All blocks shall 
contain an entry. The date shall 
correspond to the date entered on 
the related ECP. If the information 
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is not available/ use TBD (to be deter- 
mined); if it is not applicable, use N/A. 

If all data cannot be included within the 
space allocated on the forms, use attach- 
ments as necessary, with appropriate refer- 
ences in the blocks. 


6. 1.1. 2 Supersession . When a contractor is re- 
quested to resubmit an SCN, the resubmitted 
SCN shall retain the same SCN number with 

a new date. An SCN may be revised and re- 
submitted for the following reasons: 

a. A revision to the ECP. 

b. As requested by the procuring agency. 

c. Contractor initiated, e.g., typograph- 
ical corrections, supplying the latest 
engineering information, etc. 

When the revision and resubmittal of an 
SCN cannot be correlated with specific 
CCB direction, the contractor shall 
clearly state the reason for revision in 
the submittal letter. When an SCN is re- 
vised and resubmitted, the resubmitted SCN 
shall show that the previous dated SCN has 
been superseded. The contractor shall not 
cancel an SCN that has been formally sub- 
mitted to the procuring organization with- 
out formal approval of the procuring agency. 
An SCN may be cancelled prior to submission 
to the procuring agency. In such cases, 
contractor records shall show that cancel- 
lation was the result of "in-house" activity. 

6. 1.1. 3 SCN Numbers . (See Exhibit X) 

6. 1.1. 4 Preliminary/Final SCN's . Preliminary SCN's 
shall be clearly marked as such. Final 
SCN's shall be indicated by the completion 

of block 5, citing the contractual authority, 
e.g., a Contract Change Notification (CCN) . 
When mutually agreed between the contractor 
and the procurring agency, final SCN's may 
be transmitted on a periodic basis in a group 
rather than individually on an as accom- 
plished basis. 


6. 1.1. 5 Effectivity (Block 6) . Block 6 shall be 
completed to show the Contract End Item 
Serial Numbers of all articles affected 
by the SCN. 

6.1.1. 6 Effect of Change (Block 7) . Block 7 shall in- 
dicate specifically the specification change 
to be made. In those instances when an 
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ECP does not result in an actual change 
to the text of the specification, the entry 
in this block shall merely state that this 
ECP is added to the Specification Change 
Log. If the change to the specification 
is in the wording of a paragraph, include, 
verbatim, the statement of change to the 
specification, which shall call out the 
paragraph and be in one of the following 
forms: 

a . Add : 

b. Delete: 

c. Change from to 

6.2 Specification Change Log 

The Specification Change Log is used with all types of 
specifications to formally record contractually authorized 
Specification Change Notices to an approved revision of 
the specification. Therefore, the Specification Change 
Log, in addition to reflecting an identification of 
applicable SCN's, shall in fact, serve as a continuation 
of the specification configuration chart described in 
paragraph 6.3. The contractor will be required to 
submit a revised and current log, as a cover sheet, to 
each final SCN submitted for approval. The Specification 
Change Log shall be prepared to comply with sample format 
"B" . A Specification Change Log shall be prepared and 
submitted with each SCN and ECP. On those ECP's that 
do not affect the words and criteria in the specification 
and merely change hardware, the SCN prepared will indi- 
cate only that the ECP has been added to the change log. 

6.3 Specification Configuration Chart 

The Specification Configuration Chart shall be prepared 
to comply with sample format "C". The Configuration 
Chart is a summary record which identifies approved 
engineering change proposals with indivual revisions 
to the specification. The chart shall not be updated 
by the contractor, except by means of complete revision 
and updating of the entire specification, subject 
to the approval of the procuring organization and 
in accordance with this exhibit. The Specification 
Configuration Chart shall be inserted between the 
title page and the first page of the specification. 

A Specification Configuration Chart shall be prepared 
and submitted with each revision of a Specification. 
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6 . 4 Specification Revisions 

A revision is defined as the reissue of the specifi- 
cation/ with all the SCN 1 s incorporated in the body 
of the specification. A specification shall not be 
revised without specific approval of the procuring 
agency. The specification revision shall incorporate 
the information identified on the latest approved 
Specification Change Log. Configuration charts shall 
be revised to incorporate all applicable ECP entries 
which were recorded in the log. At the discretion 
of the CMO / the specification may be maintained 
by requiring replacement pages which shall accompany 
the SCN. The CMO will establish a procedure to 
indicate that a replacement page has been used 
and properly inserted in the applicable specification. 

6 . 5 Specification Identification Index 

6.5.1 The Specification Identification Index shall 
be prepared to comply with the sample format 
"D n . The Specification Identification Index 
is a record which identifies all specifica- 
tions, and all approved changes thereto. 

This document will be prepared by the con- 
tractor. Publication and distribution of the 
index will be as specified by the procuring 
agency. The procuring agency, through copies 
of CCB Directives, will keep the contractor 
advised which SCN 1 s will appear in the index. 
There will be a separate page for each speci- 
fication. The initial issue will include all 
specifications which are part of the design 
requirements baseline. As requirements for 
additional items are established, additional 
specifications will be added to the index. 

6. 5.1.1 Preparation of the Specification 

Identification Index : 

1. Nomenclature. Enter the title 
of the specification being 
reported. 

2. Enter the number of the specifi- 
cation being reported. 

3. Enter the contract end item 
number assigned by the contractor 
for this item of hardware. 
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4. Enter the initial part number 
assigned to the contract end 
item (this normally occurs upon 
release of engineering) . 

5 . Enter the date the contractor has 
scheduled for FACI of the CEI being 
reported* Enter a "C" after the 
date to indicate action completed. 

6. Enter the date scheduled for sub- 
mittal of Part II of the specification, 
as established at the critical design 
review. Enter a "C" after the date to 
indicate action completed. 

7. Enter the date scheduled for approval 
of Part II of the specification in 
question. Enter a "C" after the date 
to indicate action completed. 

8. Enter the SCN number of each approved 
SCN, and the respective ECP number. 

9. Enter the title of each SCN. 

10. Enter the specification name and number 
of each associate contractor and 
specification number affected by the 
change . 

11. Enter the SCN number for the associated 
contractor specification affected by 
the change. 

12 . Enter the name of the contractor re- 
sponsible for the CEI being reported. 
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SAMPLE FORMAT "B" 
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1 

SPECIFICATION 

NO. Si 

1 

PACE i 


SPECIFICATION CONFIGURATION CHA^T 


§ SPECIFICATION 
S ISSUE 

EC P'S 

PRODUCTION 

EFFECTIVITY 

BASIC 

ORIGINAL DESIGN ECP'S 

(LIST ALL ECP'S CONSTITUTING THE BASELINE 
CONFIGURATION ) 

(CFFECTIVITY OF 
THE SPECIFICATION 
ON PRODUCTION 
Article OR item ! 
SERIAL NUMBER, 

AS APPLICABLE). 

;! 

INCORPORATED ECP'S 


f (DATE) 

(LIST ALL ECP’S APPLIED AGAINST THE END ITEM 
SUBSEQUENT TO THE BASELINE AND CURRENT 
WITH THE BASIC ISSUE OF THE SPECIFICATION). 



INCORPORATED ECP'S 


| 

1 A 

(LIST ALL ECP'S APPLIED AGAINST THE END ITEM 
SUBSEQUENT TO THE BASIC ISSUE AND CURRENT 
WITH THE ir A n ~ ISSUE of THE SPECIFICATION^ 

(ETC.) 

(DATE) 


5 

t 

1 

r; 

INCORPORATED ECP'S 


B 


(ETC.) 

(DATE) 


. i 

j 

INCORPORATED ECP’S 


:: C 


(ETC.I j 

i 


| 

|j (DATE) 




SAMPLE FORMAT "C" 


VII-9 













EXHIBIT VII 


SPECIFICATION IDENTIFICATION INDEX 


NOMENCLATURE 


AGENDA D 


SPACECRAFT 


SPECIFICATION 


AE 60-506A 


EID 27-9370 


PART 27-97145-1 


FACI - SCHEDULED DATE 25 SEPT 63 


... . © 

SPECIFICATION, PART II * 

SCHEDULED SUBMITTAL DATE 25 AUG 63 


SPECIFICATION , PART II 
SCHEDULED APPROVAL DATE 

1 OCT t3 





BELL 256 2456S 
ACOUSTIC A IS66B 
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PROCEDURES FOR 

PROGRAM, PROJECT AND SYSTEM REQUIREMENTS 
SPECIFICATION CHANGES 


1. PURPOSE 

This Exhibit provides NASA Apollo orgainzations with require- 
ments and guidance for uniform procedures for preparing, formating 
and processing requirements changes to the Apollo Program Speci- 
fication and requirements changes to Project and System Specifi- 
cations when these specifications are not CEI Specifications. 

2. SCOPE 

This Exhibit establishes requirements for configuration control by 
NASA organizations and for submittal of requirements changes which 
will affect the Apollo Program, Project and/or System Specifications. 
This Exhibit includes procedures by which the NASA organizations shall 
document and propose changes for submittal and record formal 
approval or disapproval, as required. These procedures are based 
on: 


a. The use of program baselines to establish the departure 
points for configuration control of the system. 

b. The use of a program performance/design requirements 
specification to define and document the program requirements 
baseline, and requirements changes thereto. 

c. The use of project and system performance /design requirements 
specifications to define and document the project and system 
requirements baselines and requirements changes thereto. 

d. The use of Engineering Change Proposal (ECP) procedures in 
MIL-STD-4 80 as tailored to Apollo requirements for program 
management. 

Proposals for changing the design, production, test, retrofit, or 
support of deliverable contract end items shall be processed in 
accordance with Exhibit IX. 

3. APPLICABILITY 

This Exhibit is applicable during the Definition and Acquisition 
Phases of a program. 

4. REFERENCE DOCUMENTS 

The following documents are to be considered as reference material 
for the purpose of interpreting the requirements of this Exhibit, 
but do not form a part of this Exhibit: 
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MIL-STD- 480 30 October 

1969 

Exhibit I 

Exhibit VII 
Exhibit IX 

Exhibit X 

5. EXPLANATION OF TERMS 
See Exhibit XVII. 

6. PROCEDURAL REQUIREMENTS 

6 . 1 Background Information 


"Configuration Control-Engineering 
Changes, Deviations and Waivers." 

"Preparation of Program, Project 
and System Performance and Design 
Requirements Sepcif ications . " 

"Specification Maintenance." 

"Preparation of Engineering Change 
Proposals for Contract End Items." 

"Requirements for Configuration 
Identification Numbers." 


The Definition Phase is characterized by the completion of 
the Apollo Program Specification and the associated Project, 
System, and End Item (Part I) Specifications. These 
specifications are based on the operational requirements to 
carry out the Apollo mission. The Program Specification is 
the single authoritative top level specification which 
establishes requirements which are applicable to all Program 
elements. The Program Specification is prepared by the 
Apollo Program Office. The Project Specification is the 
single authoritative second level specification which 
establishes requirements which are applicable to a single 
Project and directly supports the Program level requirements. 
The System Specifications are the next tier of specifications 
that support the Project level requirements. The Project/ 
System Specifications are prepared by the NASA Centers and/or 
contractors as directed by the procuring agency. At the 
conclusion of the definition phase, the program will have been 
defined in terms of contract end items (CEIs) . The contract 
end item specifications shall establish the design requirements 
baseline for each end item. Thereafter, configuration control 
will be accomplished at contract end item level. 

6 . 2 General Requirements 


Requirements changes shall be processed as requirements 
ECPs in accordance with this instruction. Additionally, 
each ECP will be accompanied by a SCN. MIL-STD-480 is 
the policy document used as a guide for proposing 
requirements changes. The ECP procedures provide the 
Apollo Program Manager and Center Program Managers with: 
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a. A uniform procedure for submitting proposed changes to 
approved requirements which have defined the formal re- 
quirements baseline for program definition, design and 
development. 

b. A method for documenting the technical, fiscal and 
mission impact of the proposed change on the management 
of the program. 

6 . 3 Processing of Requirements Changes 

Approved requirements are documented in an approved specifi- 
cation. Changes in these requirements shall be documented 
by Specification Change Notices (SCNs) or by complete revision 
of the specification as provided by Exhibit VII. Specific 
requirements in the specification shall be designated as 
defining the appropriate requirements baseline. This base- 
line establishes the departure point for configuration control 
of the requirements. Changes which affect the defined base- 
line shall be further approved and documented by requirements 
ECP change procedures. All contractor changes to contract 
end items submitted for approval to the Program Manager's 
Configuration Control Board (CCB) shall be reviewed for effects 
on specification requirements. In the event the Contractor's 
ECP affects a Project/System Specification, the Program Mana- 
ger's CCB will require initiation of a requirements ECP to 
change the specification. The ECP will be processed through 
the Program Manager's CCB. All proposed changes to Project/ 
System Specifications will be reviewed for effect on the 
Program Specification. In the event a change to a Project/ 
System Specification affects the Program Specification , the 
Program Manager's CCB will require initiation of a require- 
ment ECP to change the Program Specification. The ECP will 
be processed through the Program Manager's CCB to the Apollo 
Program Office CCB. All proposed requirements changes to the 
Apollo Program Specification under consideration by the Apollo 
Program Office will be coordinated through Configuration Manage- 
ment Office channels and Program Manager's CCB for program 
impact prior to the issuance of a Program Specification Change. 

6 . 4 Approval of Requirements Changes 

The Apollo Program Director's CCB shall exercise full control 
over all decisions pertaining to program requirements ECPs. 

The Center level Program Manager's CCB shall exercise full 
control over all decisions pertaining to Project and Systems 
Requirements ECPs. The CCB chairman is responsible for making 
all decisions in accordance with established policy and direc- 
tives. He will formalize his decisions by issuing a Configura- 
tion Control Board Directive (CCBD) , (see Figure 1) . Each CCB 
member shall formalize his official position relative to the 
decision of the chairman by indicating either a concurrence 
or non-concurrence on the CCBD. Backup sheets explaining these 
positions where required will be made a part of the official 
file. The CCB will be directive on all NASA organizations. 
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6.4.1 A formal CCB agenda will be prepared and distri- 
buted for timely action on ECPs. Routine ECPs 
will normally be scheduled for 14 days of review. 
Urgent ECPs will be scheduled for a 48-hour review. 
Emergency ECPs will be scheduled for immediate 
action. 

6.4.2 CCB meetings will be held at regular intervals, or 
as called by the chairman, to meet urgent or other 
requirements. One of the following courses of 
action will be taken: 

a. The ECP may be approved as written. 

b. The ECP may be disapproved, with reasons clearly 
stated . 

c. The ECP may be approved with specific changes 
clearly stated. 

d. Decision may be deferred for investigation, with 
responsibility for resolution assigned to a 
specific person. 

e. Decision may be referred to higher headquarters 
if judged to be beyond the authority of the CCB. 

6.4.3 The decision or other action will be documented on 
the CCBD . The CCB action shall not be complete 
until all elements of the CCBD are completed and the 
form signed by the CCB chairman. 

6 . 5 Preparation of the Configuration Control Board Directive 

The Configuration Control Board Directive has been prepared 
for use by the Apollo Program Director's CCB and the Pro- 
gram Manager's CCB. Items 3, 6, 7, 8, 9, 10, 12, 18 and 
20 will not be used on CCB Directives related to Program, 
Project and System Specification Requirements Changes. 

6 . 6 Preparation of the ECP Form 

The ECP form in MIL-STD-480 shall be used as a guide for 
formal submission of requirements ECPs. 

6.7 Waivers and Deviations 


When an authorized departure from approved requirements is 
necessary, waivers or deviations as applicable may be 
processed in accordance with the procedures, and forms, 
prescribed by MIL-STD-480. 
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□ SV □ AGE O FAC NASAORG.. 

□ TRAINING □ GIE QDS RPIE 

(2) CCBD NUMBER CONFIGUI 


(3) CONTRACTOR: 


(4) ECP NO. 


(5) SUPERSEDES ECP NO. 


(6) END ITEM NO. 


(7) END ITEM PART NO. 


(8)TCTR NO. & TYPE 


PART NO CHANGE: 

Q YES □ NO 


(10) SPARES AFFECTED 

Q YES Q NO 


(11) INTERFACE REQUIREMENTS 




(12) DESIGN 

□ YES □ NO 


(13) ECP NOTED IN BLOCK (4) IS 

□ APPROVED AS WRITTEN 

□ DISAPPROVED 

□ APPROVED WITH CHANGES. 
AS NOTED BELOW 


(14) SPECIFICATION NO. 


(15) SPECIFICATIONS AFFECTED: 


(19) ECP TITLE 


(4A) DATE: 


DATE: DAY 

MO. 

YR. 

SUPERSEDES 

DAY 

MO. YR. 

ISSUE OF 




(5A) DATE: 


( 21 ) 


FIRST LAST 


(20) NOMENCLATURE, CONTRACT END ITEM 


EFFECTIVITIES 
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PREPARATION OF 

ENGINEERING CHANGE PROPOSALS 
FOR CONTRACT END ITEMS 


1 . PURPOSE 

This Exhibit provides NASA Apollo organizations and contractors 
with requirements and guidance for uniform procedures for pre- 
paring, formating, and processing engineering changes to contract 
end items of equipment and facilities and Direct Support Real 
Property Installed Equipment (DS-RPIE) . 

2 . SCOPE 

This Exhibit establishes requirements for configuration control 
and for submittal of Engineering Change Proposals (ECP's) in 
accordance with MIL-STD-480. These procedures are based on: 

a. The use of management baselines to establish the 
departure points for configuration control of 
contract end items. 

b. The use of contract end item detail specifications to 
define and document these baselines, and engineering 
changes thereto. 

c. The use of MIL-STD-480 as written for its primary 
purpose. 

The procedures in this exhibit shall be used for proposing 
changes in all contract end items of equipment and facilities 
and DS-RPIE to be formally accepted by the National Aeronautics 
and Space Administration for use on the Apollo Program. This 
includes both system and non-system contract end items. 

3. APPLICABILITY 

This Exhibit is applicable to contract end item definition, design, 
development, fabrication, and test phases of the program. 


4 . REFERENCE DOCUMENTS 

4 . 1 Applicable Documents 

The following documents of the exact issue shown, or parts 
thereof as further described, form a part of this Exhibit: 

MIL-STD-480 30 October 1968 "Configuration Control - 

Engineering Changes, Deviations 
and Waivers" 
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4.2 Reference Documents 


The following documents are contained in the text for 
reference purposes only, and do not form a part of this 
Exhibit: 


Exhibit II 
Exhibit III 
Exhibit IV 
Exhibit V 
Exhibit VII 


"Preparation of Contract End Item Detail 
Specification (Prime Equipment)." 

"Preparation of Contract End Item Detail 
Specification (Facilities) 

"Preparation of Contract End Item Detail 
Specification (Identification Item) . " 

"Preparation of Contract End Item Detail 
Specification (Requirement Items)." 

"Specification Maintenance." 


Exhibit X 


"Requirements for Configuration Identifi- 
cation Numbers." 


Exhibit XI - "Requirements for Configuration Identifi- 
cation and Acceptance Contract End Items 
and Related Data." 


5. EXPLANATION OF TERMS 
(See Exhibit XVII.) 

6. PROCEDURAL REQUIREMENTS 

6 . 1 Background Information 


The Apollo Program Managers will manage the acquisition of 
a contract end item (CEI) by the use of contract end item 
specifications in conjunction with MIL-STD-480. Together, 
these documents establish the basis for configuration 
control of the CEI. Partial configuration control is 
implemented at the start of the acquisition phase, i.e., 
when the contractor is authorized to proceed with detail 
design and development in accordance with approved require- 
ments in the CEI specification. Full configuration control 
is implemented at the time of acceptance of a CEI 
manufactured to the configuration required for a particular 
series of space vehicles. Thus, programs for contract end 
items of equipment and facilities are defined by detail spec- 
ifications are phased for progressive configuration control 
to the requirements specified therein, and are controlled to 
these requirements by the application of MIL-STD-480. 

This method of programming and configuration control is 
illustrated in Figure 1, and is explained below. 
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6 . 2 General Requirements 

Formal configuration control, in accordance with this 
Exhibit, shall be implemented and maintained on all 
programs involving the formal acceptance of contract 
end items of equipment or facilities and DS-RPIE. 
Configuration control shall be implemented and maintained 
by use of the program phasing and baseline concepts of 
configuration management. These concepts are illustrated 
in Figure 1 and are related to the design, development and 
fabrication activities of a typical program. Variations 
in the typical program, e.g., a program for the delivery of 
just one item, do not alter the necessity for the configura- 
tion management concepts and elements shown in Figure 1. 

6.2.1 Definition Phase During the Definition Phase, the 
Apollo Program Specification shall be completed. 

The end of the Definition Phase is denoted as the 
point wherein the Program, Project and System 
specifications and the CEI specifications. Part I, 
are complete. 

6.2.2 Acquisition Phase 


6. 2. 2.1 Design Requirements Baseline 

6. 2. 2. 1.1 The procuring agency will, at 

the start of the Acquisition Phase, 
perform a Preliminary Design 
Review to approve Part I of the 
CEI specification; and will 
designate specific requirements 
therein as defining the design 
requirements baseline; and will 
authorize the contractor to 
proceed with detail design and 
development of the CEI, including 
further development of the 
specification. 

6. 2. 2. 1.2 The design requirements baseline 
is a defined departure point for 
configuration control. Once a 
design requirements baseline has 
been defined and approved, design 
and development of the CEI shall 
be accomplished in accordance with 
baseline requirements unless formal 
approval to change these require- 
ments is obtained from the procuring 
agency. The contractor may propose 
such a change and shall process any 
change to Part I of the CEI speci- 
fication as a Class I change when 
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the change affects a requirement 
in the specification that has been 
designated by the procuring agency 
as defining the design require- 
ments 1 baseline . 

6. 2. 2. 1.3 The contractor shall document 
specification changes by 
Specification Change Notice (SCN) , 
or by revision of the specification, 
as provided in Exhibit VII and as 
directed by the CMO. 

6. 2. 2. 2 Product Baseline 


6.2. 2.2.1 The contractor shall, as part of 
his design and development effort, 
prepare a Contract End Item Detail 
Specification, Part II, "Product 
Configuration and Acceptance Test 
Requirements," which specifies the 
requirements for delivery of all 
CEI's which are to be formally 
accepted by NASA. This includes 
first acceptance, and all subsequent 
acceptances, irrespective of 
intended use. The specified require- 
ments of Part II are a product of 
released engineering design and all 
CEI's shall be manufactured in 
accordance with this released 
engineering design. 

6. 2. 2. 2. 2 The contractor shall submit to the 
procuring agency for formal approval 
a complete baseline issue of the 
specification (Parts I and II) no 
less than 30 days prior to the 
acceptance of that CEI which will 
formally implement the product 
configuration baseline. This issue 
shall be verified as representing 
the status of released engineering 
for that CEI, and as accurately 
documenting the product configura- 
tion of the CEI. 

6. 2. 2. 2. 3 The procuring agency will formally 
approve the complete specification 
at the time of acceptance of that 
CEI, which establishes the Product 
Configuration Baseline. This will 
normally occur as part of the FACI 
held at the contractor's plant or 
site of construction. 
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6.2, 2. 2. 4 The contractor shall, after the 
complete specification has been 
approved, process any change to 
the specification as a Class I 
engineering change. Also, any 
change to CEI's to be accepted 
after establishing the product 
configuration baseline shall be 
processed in accordance with the 
requirements in MIL-STD-480. 

6 . 3 MIL-STD-480 Requirements 

MIL-STD-480 shall be used, as required by this Exhibit, 
for the preparation of ECP's submitted for approval to 
change the design requirements or Product Configuration 
baseline of a contract end item. The following subpara- 
graphs supplement the standard and unless specifically 
stated otherwise, MIL-STD-480 applies as written. 

6 . 4 Processing and Approval of ECP 1 s 

The instructions in this paragraph apply to the processing 
and approval of all ECP 1 s for a contract end item. MIL- 
STD-480 shall apply as written, and as supplemented in the 
following subparagraphs to provide for Configuration Con- 
trol Board (CCB) procedures. 

6.4.1 Submittal of ECP's The contractor shall submit all 
ECP's as required by MIL-STD-480. ECP's requiring 
coordination shall be distributed in parallel as 
follows : 

a. The local Government representative. 

b. The Configuration Control Board. 

c. The affected contractor. 

6.4.2 Approval of Class I Changes Approval of ECP's for 
contract end items shall be in accordance with MIL- 
STD-480. ECP's shall be approved by the appropriate 
Program Manager's Configuration Control Board, with 
the exception of Program Performance Design Require- 
ments Baseline, which will be approved by the Apollo 
Program Director's CCB. The CCB is not a voting 
board. The Program Manager or a CCB Chairman acting in 
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his behalf, is responsible for making all decisions 
in accordance with established policy and directives. 

He will formalize his decisions by issuing a 
Configuration Control Board Directive (CCBD) which 
will be directive on the Contracting Officer of the 
procuring agency. The procuring agency will reflect 
the exact requirements of the CCBD in the contract 
authorization. This authorization shall constitute 
the sole authority for the contractor to implement 
the change . ECP's requiring approval of the Apollo 
Program Director's CCB will be transmitted to the 
appropriate Program Manager's CCB. for implementation 
after approval. 

6. 4.2.1 A formal CCB agenda will be prepared and 
distributed for timely support of sub- 
mitted ECP's. Routine ECP's will normally 
be scheduled for 14 days of review. Urgent 
ECP's will be scheduled for a 48-hour 
review. Emergency ECP's will be scheduled 
for immediate action. 

6.4.2. 2 CCB meetings will be held at regular intervals, 
or as called by the Chairman, to meet emer- 
gency and other requirements. The contractor 
may be invited to attend CCB meetings to 
present technical data supporting his ECP. 

One of the following courses of action will 
be taken: 

a. The ECP may be approved as written. 

b. The ECP may be disapproved, with 
reasons clearly stated. 

c. The ECP may be approved, with 
specific changes clearly stated. 

d. Decision may be deferred for 
investigation, with responsibility 
for resolution assigned to a specific 
person. 

e. Decision may be referred to higher head- 
quarters if judged to be beyond the 
authority of the Center CCB. 

6.4.2. 3 The Program Manager's CCB shall assure that 
changes having intra-center interface 
considerations have been coordinated and 
agreements established. The interface change 
shall be recorded in the CCBD. The Program 
Manager's CCB shall coordinate with the appro- 
priate Apollo Coordination Panel those changes 
that affect another Center's end item. After 
Panel agreement, the Program Manager's CCB shall 
issue a CCBD implementing the interface 
agreement. 
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6.4. 2.4 The decision or other action will be 
documented in the CCBD. (See Exhibit VIII 
for format of CCB Directive.) Each member 
will formalize his concurrence or non- 
concurrence on the CCBD. The CCB action 
shall not be completed until all elements 
of the CCBD are completed, and the form 
signed by the CCB Chairman. 

6. 4. 2. 5 Completed CCBD forms for approved ECP 1 s shall 

be forwarded to the Contracting Officer who will 
authorize the contractor to proceed. 

6.4.3 Submittal and Approval of Class II Changes Class II 
engineering changes shall be handled as required in 
MIL-STD-480. In addition, all changes incorporated 
in the CEI specification, and which do not require 
submittal of an ECP, shall be submitted as 
follows : 

6.4. 3.1 The contractor shall submit a copy of the 
SCN, or revision, for each Class II change 
to the designated local Government 
representative of the procuring agency at 
the time the SCN, or revision, is prepared 
and authorized by the contractor. 

6. 4. 3. 2 The designated local Government representative 
will review and may, within two working days 
of receipt, disapprove the classification of 
the SCN, or revision, as a Class II change. 

If the contractor disagrees with the 
determination of the Government representa- 
tive, he may submit the SCN to the CCB for 
final resolution of the classification. 

6 . 5 Preparation of the ECP Form 

The contractor shall use the ECP Form and/or message for- 
mat in MIL-STD-480 for the preparation of ' all ECP 1 s . 

The requirements of MIL-STD-480 shall apply to the prepara- 
tion of all ECP's. The standard identification numbers in 
Exhibit X shall be used on all ECP'S/ or as directed by the 
procuring activity. 
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REQUIREMENTS FOR CONFIGURATION 
IDENTIFICATION NUMBERS 


1. PURPOSE 

This exhibit provides NASA and contractor organizations with 
requirements for assigning and controlling configuration identifi- 
cation numbers. 

2 . SCOPE 

This exhibit establishes a system for assigning a complete set 
of identifying numbers to be used in controlling the configura- 
tion of all contract end item equipments, facilities, sites and 
spares. The numbers are: 

a. Specification identification numbers 

b. Contract end item numbers 

c. Serial numbers 

d. Drawing and part numbers 

e. Change identification numbers 

f. Code identification numbers 

These numbers are the only identifiers to be used to formally 
and precisely identify configuration. This exhibit fully defines 
the method of construction and meaning of the numbers. The set, 
composed and assigned as required by this exhibit, shall be used 
to identify equipments and documents as required by Exhibit XI. 

3. APPLICABILITY 

This exhibit applies to the configuration identification of all 
contract end item equipments, facilities, and spares which are 
formally accepted by the procuring agency. It applies to all 
contracts with the procuring agency for systems engineering or 
system integration involving these deliverable items. Contractors 
to the procuring agency shall be responsible for the compliance 
of their subcontractors, vendors and suppliers. 

4. REFERENCE DOCUMENTS 

4 . 1 Applicable Documents 


The following documents of the exact issue shown, or part 
thereof as further described, form a part of this exhibit: 
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MIL- STD- 100 A 

1 October 1967 

"Engineering Drawing 
Practices" 

MIL-STD-480 

30 October 1968 

"Configuration Control 
Engineering Changes , 


Deviations and Waivers" 


5. EXPLANATION OF TERMS 

See Exhibit XVII. 

6. PROCEDURAL REQUIREMENTS 

Configuration identification numbers are assigned by contractors 

rather than by the procuring agency to: 

a. Assure the timely availability of all required configuration 
identifiers for correct entry on engineering data when these 
data are initially prepared. 

b. Improve the effectiveness of both contractor and procuring 
agency operations by establishing a complete responsibility 
for identification at the source of design and manufacture. 

c. Reduce time delays and costs which may result from improper 
identification, misinterpretation and attendant rework. 

6 • 1 General Requirements 

The formal requirements of configuration management have sub- 
stantially increased the significance of the numbers used to 
identify the configuration of a product. These configuration 
identification numbers are used in combination to provide com- 
plete identification of the product as required for technical 
and contractual purposes. Table "A" abstracts the prime 
characteristics, use, and relationships of the configuration 
identification numbers. 

6.1.1 Contractor Responsibility . The contractor shall assign 
and control configuration identification numbers in 
accordance with this exhibit without further approval 
of the procuring agency. 

6.1.2 Numbers Assigned by Other Design Activities . Where 
the contract end item of a contractor incorporates the 
design of a Government agency or the design of a sub- 
contractor, vendor or supplier, the contractor shall use 
the configuration identification numbers assigned by 
these design activities without reidentification except 
as specifically authorized in this exhibit. 
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6.1.3 Use of Additional Identifiers . Numbers other than 

the configuration identification numbers described 

in this exhibit shall not be used for configuration 

management purposes. Specific examples include: 

a. Registration numbers (e.g., "tail" numbers) 
assigned by the Government. 

b. Type designations for the contractor's contract 
end item, or component thereof, assigned by the 
Gove rnment. 

c. Other reference designations (e.g., aero numbers) 
used by the Government. 

d. Federal Stock Number assigned by the Government to 
provide a Government Inventory Control. 

e. "Manufacturing" or "production line" numbers used 
by the contractor to denote the sequence in which 
contract end items are manufactured. 

f. "Synthetic" part numbers used by the contractor to 
denote a subassembly of manufacture not covered by 
an engineering assembly drawing. 

g. Material codes used by the manufacturer for material 
control . 


6.2 Specification Identification Numbers 


The contractor shall assign and control the identification 
numbers for specif ications , specification change notices 
(SCNs) and specification revisions as required by the following 
subparagraphs. These numbers shall identify all specifications 
and standards required to control design of systems/equipments 
to be formally accepted by the procuring agency. 

6.2.1 Composition of Specification Identification Numbers . 

6. 2.1.1 Composition of Specification Numbers . 

Contractor prepared specification documents, 
shall be identified by a number consisting of 
a document identification number and suffix 
codes in accordance with paragraph 6.2.2, 
and shall not exceed a total of 15 characters. 
(See Figure 1A) 

6. 2. 1.2 Composition of Specification Change Notice 
(SCN) Numbers. SCNs shall be identified by a 
number consisting of an SCN number, a dash, a 
specification page number and an SCN suffix 
letter assigned as required in paragraph 
6.2.3. (See Figure IB) 

6. 2. 1.3 Composition of Government or Industry 
Specification Numbers . Government or 
Industry specifications and standards 
shall be identified 
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by the number assigned by the Government agency 
or industry association to the specif ication 
or standard document. These specifications and 
standards shall not be reidentified by the 
contractor unless altered or selected. 

6.2.2 Assignment of Specification Numbers . The contractor 

shalT assign one number - to each specification document 
to be prepared and maintained by the contractor. The 
number shall be assigned as follows: 

6.2.2. 1 Document Identification Number . The contractor’s 
document identification number, including 
combinations of numerals, letters and dashes, 
shall follow the prefix code. Once assigned to 
an approved specification, the number shall not 
thereafter be changed or reassigned to another 
specification . 

6. 2.2. 1.1 The document identification number 
may be codified in accordance with 
the contractor's internal systems 
and procedures providing that such 
codes will not be changed and do 
not duplicate the suffix informa- 
tion described in paragraph 6. 2. 2. 2. 

6. 2. 2. 1.2 The contractor shall assign a new 
document identification number to 
an addendum specification which has 
been created from an existing 
specification. An addendum specifica- 
tion is a new and complete specifica- 
tion in every sense. It shall be 
maintained by its own SCN and 
revision sequence which shall be 
independent of the change sequence 
applicable to the specification from 
which the addendum was created. 

6.2. 2.2 Specification Suffix Code . The suffix code shall 
follow the document identification number. It 
shall consist of an upper case (capital) letter 
assigned in alphabetical sequence to identify the 
latest approved revision of the specification. 

6. 2. 2. 2.1 When it is necessary to refer to one 
item in a requirement items specifica- 
tion, the item shall be identified by 
the specification number described in 
paragraph 6.2.2, and an addi- 
tional suffix code consisting of the 
paragraph number in Section 3 of the 
specification which identifies the 
item (refer to Exhibit V) . This item 
code shall follow the revision letter. 

6.2. 2. 2. 2 When a component specification applies 
to more than one source, each source 
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shall be identified by the 
specification number described in 
paragraph 6.2.2 and an 
additional suffix code consisting 
of a separate dash number tabulating 
each alternate source in the 
specification. This source code 
shall follow the revision letter. 

6.2.2. 3 Examples of specification identification 
numbers are shown in Table B. 

6.2.3 Assignment of Specification Change Notice (SCN) Numbers . 

The contractor shall assign one SCN number for each SCN 
to be prepared by the contractor. One SCN is required 
for all changes, to a single approved specification, to 
be approved by one ECP (refer to Exhibits VII, VIII, and 
IX) . The SCN number shall identify the SCN as part of, 
and subordinate to, the specification which it changes. 

The number shall be assigned as follows: 

6.2. 3.1 The first character (s) shall be a numeral(s) 
to identify one SCN for one specification and 
its assigned sequence within that specification. 
This SCN number shall be assigned in numerical 
sequence beginning with the number 1 (one) for 
the first SCN number assigned. 

6.2. 3.1.1 The SCN sequence number shall be a 
common identifier for all SCN sheets 
prepared as part of one specification 
change . 

6. 2. 3. 1.2 Once an SCN has been submitted to 

the procuring agency, its SCN sequence 
number shall not thereafter be 
changed or assigned to another SCN 
within the same specif ication , even 
though the SCN is subsequently 
disapproved. 

6.2. 3.2 The SCN sequence number shall be followed by a 
dash and, on each sheet of the SCN, the page 
number of the specification affected by that 
sheet of the SCN. 

6.2. 3.2.1 The content of an SCN sheet is 
limited to one page of a specification. 

6. 2. 3. 2. 2 Multiple sheets identified by the 
same SCN sequence numbers are used 
where more than one specification 
page is affected (See Exhibit VII) . 

6.2.3. 3 The specification page number shall be followed 
by a lower case suffix letter assigned in 
alphabetical sequence within one SCN page number. 
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This suffix shall be applied only when more 
than one SCN sheet of one SCN is required to 
describe the change for a single specification 
page. 

6. 2. 3. 4 Examples of SCN numbers are shown in Table B. 

6.2.4 Specification Identification Number Assignment Log . 

The contractor shall establish and maintain a Specifica- 
tion Identification Number Assignment Log of all 
specification numbers and SCN numbers assigned to 
specifications prepared and maintained by the contractor. 
The log shall be readily available for routine 
surveillance by the local representative of the procuring 
agency on a non-inter ference-with-production basis. 

6.2.5 Changes in Specification Numbers . 

The document identification number portion of a 
specification number is a permanently assigned non- 
duplicated number which identifies the basic specifica- 
tion document. Subsequent changes and revisions to 
these documents shall be identified in accordance with 
the following subparagraphs: 

6. 2. 5.1 Rough drafts prepared for coordination prior 
to formal approval by the procuring agency 
shall be identified by a document identifica- 
tion number only. No revision letters or SCN 
numbers shall be assigned. 

6. 2. 5.1.1 The revision letter "A" shall be 
assigned to the first issue formally 
approved by the procuring agency. 

6.2. 5.1.2 Each subsequent change to these 
approved specifications shall be 
identified by an assigned SCN 
number unless otherwise directed 
by the procuring agency in 
accordance with paragraph 6.2. 5.1. 3. 


6. 2. 5. 1.3 Revision letters shall be assigned 
only when directed by the procuring 
agency and as specifically described 
in a Configuration Control Board 
Directive (CCBD) to incorporate 
previously approved SCNs and/or major 
specification revisions. 

6. 2. 5. 1.4 Component specifications which are 
contractually required to be formally 
approved by the procuring agency 
(refer to Exhibit VI) shall, from the 
time of formal approval, be controlled 
by the use of SCN numbers and re- 
vision letters assigned in accordance 
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with paragraphs 6.2. 5.1.2 and 
6. 2. 5. 1.3. When formal approval 
is not required the contractor 
shall assign revision letters , 
SCN numbers and/or completely 
revise component specifications 
in accordance with his own 
standard practice. 

6 . 3 Contract End Item CEI Number 


The CEI number is a permanent number assigned by the 
contractor to identify all units comprising one contract 
end item family (type-model-series) . 

6.3.1 Definition of a Contract End Item Type-Model-Series. 

A contract end item type-model-senes constitutes a 
block of one or more deliverable CEI units to which 
all of the following apply: 

a. The type-model-series shall be a line item 
requirement in a contract. 

b. All units shall be designed to and controlled 
by one contract end item detail specification. 

c. All units shall be identified and documented by 
one top drawing and a subordinate structure of 
installation , subassembly and detail drawings. 

d. Within this basic drawing structure, configuration 
differences in production between untis shall be 
identified and documented by adding and/or limiting 
the design application of parts and assemblies 
comprising the affected units. 

e. Each unit shall be formally accepted by the procuring 
agency and accountability transferred by means of a 
receiving and inspection report, DD Form 250 or NASA 
equivalent. 

f. The type-model-series shall be the foundation for 
provisioning spares (by a contractor or the procuring 
agency) and for the preparation of operating and 
maintenance manuals for the CEI type-model-series. 

The contract end item type-model-series , as identified 
by the CEI number, establishes the contractual inter- 
face between the contractor and the procuring agency, 
and is the level of control for all design requirements 
changes (to CEI detail specification) , and Class I 
engineering changes (to design configuration) to be 
formally approved by the procuring agency (see Exhibit 
IX) . All Class I engineering changes will be approved for 
production and/or retrofit incorporation in all 
unexpended units within a type-model-series or, if 
limited to incorporation on some but not all units, 
the series designation of the affected units shall be 
changed to establish a new series. 
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6,3.2 Assignment and Control of CEI Numbers . 

The CEI number shall be assigned by the contractor 
at the time the document identification number of 
the CEI specification is assigned, or the first pro- 
duction drawing for the CEI is released, whichever 
occurs first. 


6. 3.2.1 The CEI number shall consist of a basic 
number for the type-model-series followed by 
a code letter for the series. 

6. 3. 2. 2 The basic number, including combinations of 
letters, numerals and dashes, shall precede 
a series code. Once assigned to a contract 
end item whose design, development and/or 
manufacture has been contractually authorized 
by the procuring agency, this portion of the 
CEI number shall not thereafter be assigned 
to another contract end item type and model. 

6.3.2. 3 The basic number may be, or include, 
portions of the contractor's specification 
document identification number and/or top 
drawing number for the CEI, at the contractor's 
option . 


6. 3.2.4 The last digit of the CEI number shall be the 
series letter "A." Once assigned this letter 
shall be the permanent series designation for 
all contract end items comprising the type- 
model-series, including follow-on procurement 
within the series. 


6. 3.2. 5 A new series designation for the same basic 

number shall be assigned only when contractually 
authorized by the procuring agency wherein all 
of the following apply: 

a. The new series is specified by a new contract 
end item specification, or specification 
addendum. 

b. All units in the new series are identified 
by a new top drawing. The subordinate 
structure of installation, subassembly and 
detail drawings may be made applicable as 
required to the new series by a common 
release which shows design application for 
both series (see Exhibits XI and XII) . 

c. A new basis for acceptance, provisioning, 
operations and maintenance is established. 


6.4 Contract End Item Serialization 


Contract end item serial numbers are used in configuration 
management to: 
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a. Identify individual contract end items within a 
family of CEIs. 

b. Establish this identity as a specific address for 
all contractual and management actions; this address 
to be the same as the effectivity (usage) of 
engineering design and engineering changes which 
result from these actions. 

c. Relate the specific part number configuration of 
each contract end item to their engineering 
effectivity so that it will be built, allocated and 
changed in accordance with required design. 

The contractor shall assign all serial numbers in accordance 
with this exhibit, and these serial numbers shall be the only 
serial numbers used by the contractor and the procuring 
agency as a CEI unit identification and engineering 
effectivity for configuration management. 

6.4.1 Assigning Contract End Item Serial Numbers . 

These numbers shall begin with the numeral 1 (one) 

and shall be assigned in unbroken numerical progression 
within one contract end item type-model-series. The 
CEI number and serial number shall denote the engin- 
eering effectivity of design. The CEI number arid 
serial number shall be affixed to each contract end 
item unit manufactured and allocated in accordance 
with this engineering effectivity and design (see 
Exhibit XI) . 

6. 5 Drawing and Part Number 

The drawing and part number is assigned by the contractor to 
identify, in common, all parts and assemblies that are inter- 
changeable in all applications where used. A part number must 
not be changed if it is still interchangeable after incor- 
porating a change. This action would create excess inventories 
and artificial shortages. The prime function of a part 
number, therefore, is to control assembly and replacement on 
the basis of interchangeability. The determination of non- 
interchangeability is a technical consideration. Part numbers 
shall not be changed for any other purpose (e.g., to indicate 
that an assembly includes a change but which did not make the 
assembly non-interchangeable) . 

6.5.1 Assignment of Drawing and Part Numbers . Drawing and 
part numbers, for other than standards, shall be assigned 
by the contractor in accordance with the requirements 

in MIL-STD-100 

6.5.2 Changing Part Numbers . The contractor shall change the 
part number in accordance with the requirements in MIL- 
STD-100, and the following requirements. 

6.5. 2.1 When a material, process or protective treat- 
ment is changed to such an extent that any of 
the conditions in MIL-STD-100 , exist.. 
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6.5. 2. 2 When a physical part, component, subassembly 
or contract end item is reworked in production 
or retrofit by a kit into a later number 
version of the item, and is completely inter- 
changeable with all items identified by the 
later number, the physical part shall be 
reidentified to the number of the later version. 

6.5.2. 3 The contractor may establish a part or com- 
ponent for which the contractor is the design 
activity as a company standard, identified by 
a standard specification identification 
number when all of the following apply: 

a. The part or component has a multiple 
usage and is expected to have a design 
application in more than one contract end 
item. 

b. The part or component is non-repairable 
(throw away) and will not be provisioned 

by the procuring agency or contract 
below the level identified by the 
standard specification identification 
number. 

c. The part or component is completely 
specified in a specification document, 
specification control drawing or source 
control drawing with respect to performance, 
durability, reliability, form, fit, 
qualification, and inspection requirements. 

d. Unless otherwise concurred in by the 
procuring agency, one or more alternate 
sources is approved and qualified to 
supply the item. 

6.5.3 Initiation of Part Number Changes . Engineering changes 
may be incorporated and documented by drawing change 
letter control only (without changing part number) up 
to the cut-off date established by the contractor for 
incorporation of changes in the factory on the first 
unit of a CEI type-model-series, or component thereof, 
to be formally accepted by the procuring agency, and 
providing that all such changes are made effective on 
CEI serial number 1 and on. Thereafter drawing change 
letter control shall continue and, in addition, part 
numbers shall be changed as required by paragraph 
6.5.2. 

6.5.4 Changes in Higher Level Assembly Part Numbers . 

When a CEI contains a non-interchangeable item, the 
part number of the non-interchangeable item of its 
next assembly, and of all progressively higher 
assemblies shall be changed only up to and including 
the assembly where interchangeability is re-established. 
Part numbers shall not be changed above this level of 
assembly for any reason. 
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6 . 6 Part Number Serialization 

The contractor (or his subcontracted design activity) shall 
serialize all engineering critical and logistic critical 
components (refer to Exhibit VI) of a CEI by drawing and part 
number. The contractor may also serialize other assemblies or 
parts of a contract end item as he may require. 

6.6.1 Assigning Serial Numbers to Components, Assemblies 

and Parts . The drawing number shall be the base for 
serializing a critical component , assembly, or part. 

6. 6. 1.1 Serial numbers shall be permanently assigned 
in numerical sequence within the drawing 
number. 

6. 6. 1.2 A new serial number sequence shall not be 
assigned when the part number is changed to 
identify a non-interchangeable design. 

6.6.1. 3 The serial number of a reworked or retrofit 
item shall not be changed even though the 
item has been identified by a new part number. 

6 . 7 Change Identification Numbers 

The change identification number is a packaging number 
assigned by the contractor to package all engineering data 
defining an engineering change, and is used to control , sequence 
and account for production and retrofit accomplishment of the 
change. These chanqes are classified in accordance with 
MIL-STD-48C >. -This .classification determines 'the method used 
to compose a change identification number. 


6.7.1 Composition of a Class I Change Identification Number . 

The complete Class I change identification number con- 

tains three basic parts* These are: 

a. Prefix designations which relate the change to the 
contract end item, to the contractor and to the 
system program affected by the Class I change. 

b. An eleven (11) character ECP sequence number which 
identifies each individual Class I engineering change. 
The ECP is the basic "delta" increment for config- 
uration control and accounting by the procuring 
agency of the approved system and contract end item 
configuration . 

c. A correction code to distinguish between ECP 
documents containing minor editorial corrections 
and the original copy. 
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The contractor shall construct the complete Class I 
change identification number in accordance with the 
pattern shown in Figure 2. The example identifies 
the 31st ECP processed by contractor 15802 for the 
114 system. The change affects CEI 376524B and other 
CEIs produced by the contractor as noted by the ECP 
dash number. These requirements for constructing a 
Class I change identification number include and 
incorporate the requirements in MIL-STD-480. 

6. 7.1.1 The system designation number will be provided 
to all contractors by the procuring agency 

at the beginning of a system program. 

6. 7.1.2 The contractor shall assign ECP numbers 
consecutively from a separate series for 
each system program (i.e. , program identi- 
fied by a system designation number) , or the 
ECP series may be established in accordance 
with MIL-STD-480 for contract end items 

not a part of a system program. The first 
ECP processed shall be ECP number 1 (one) . 

Once assigned the ECP number shall be retained 
for all subsequent submissions of the pro- 
posal, and for all ECP Type, revisions and/ 
or correction codes which may be appended to 
that number. 


6. 7. 1.3 Class I engineering changes affecting more 
than one CEI number under the cognizance of 
a single contractor shall be identified by 
a basic ECP number with a separate dash 
number assigned for CEI affected. Each 
dash numbered ECP must be complete in itself 
for the CEI change being proposed. The pur- 
pose of dash numbers is to relate all CEIs 
affected by a change. 

6. 7.1.4 The contractor shall assign one of the 
following type codes to each ECP. The 
type code may be changed to reflect a new 
condition of the ECP if it is necessary on 
resubmittal of a proposal. 


?e of ECP 


:>e Code 


Preliminary P 

Formal F 


Class I ECP justification codes and change 
priorities shall be assigned in accordance 
with the requirements of MIL-STD-480. 
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6 -7,1.5 The contractor shall identify each formal 
revision to the ECP with an "Rl" for the 
first revision, "R2 n for the second revision, 
etc. 

Note: The requirements for using the 

revision code are described in 
Exhibits VIII and IX. 

6. 7. 1.6 The ECP sequence number shall consist of the 
basic ECP number followed by a dash and dash 
number, a type code, a revision identification 
and a correction code as applicable. The 
total number of characters for numerals, 
dashes and letters shall not exceed eleven 
(11) . The ECP sequence number is the number 
which is shown in configuration index and 
accounting reports as the ECP number because 
reporting formats are designed to otherwise 
display prefix information. 

6. 7.1. 7 The contractor shall denote that an ECP 
document has been corrected editorially but 
not otherwise changed by a "Cl" for the first 
correction, M C2" for the second correction, 
etc. The correction sequence shall begin 
anew for each revision. 

EXAMPLE: Rl-Cl is the first correction of the 

first revision; R1-C2 is the second 
correction of the first revision? 
R2-C1 is the first correction of the 
second revision. 

6.7.2 Composition of a Class II Change Identification 

Number ^ Class II change identification numbers may 
be constructed in accordance with the contractor's 
internal systems and procedures providing that these 
procedures are compatible with MIL-STD-480. 

6.8 Code Identification Numbers 


This shall be the five-digit number of the contractor or 
Government agency as shown in Cataloging Handbook H4-1, 
"Federal Supply Code for Manufacturers." 

6.8.1 Contractor Code Identification Numbers . Contractors 
having more than one division, each having an H4-1 
code, shall use the code of the division which is the 
design activity, and shall also use the code of the 
division which is the manufacturer when a different 
division (refer to Exhibit XI) . 

6.8.2 Government Agency Code Identification Numbers . When 
a Government agency is a design activity or a manu- 
facturer, the H4-1 code of the responsible Government 
agency shall be used. If no H4-1 code has been 
assigned, the mnemonic abbreviation of the agency shall 

be used. 
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CONFIGURATION IDENTIFICATION NUMBERS 


NUMB E R CHARACTERISTIC , USE AND RELATIONSHIP 


Specification 

Number 

Requirements 

Number 

Denotes technical requirements. 
Is is used to identify system, 
contract end item and component 
specifications and relate these 
documents to program baselines. 
It is also used to identify com- 
pany standards. 

Contract End 
Item Number 
(CEI ) 

Permanent 

Number 

Denotes type-model series. It 
is used to identify the level at 
which technical and contractual 
requirements shall be managed. 

Drawing and 
Part Number 

Transient 

Number 

Denotes interchangeability and 
non-interchangeability. It is 
used to control assembly and re- 
placement at all levels includ- 
ing the contract end item itself. 

Serial 

Number 

Permanent Sequence 
Number 

1. Used with a CEI number to 
denote each unit in a type-model- 
series and be the engineering 
effectivity to which all management 
actions are specifically addressed. 

2. Used with a drawing and part 
number to denote each unit in a 
family of non-in terchangeable parts 
which, when reworked or modified 

to be interchangeable, are reidenti- 
fied the same. 

Change 

Identification 

Number 

Packaging 

Number 

Denotes the content of a change. 
It is used to package, control, 
sequence and account for all en- 
gineering production and retrofit 
actions required for a single 
change. 

Code 

Identification 

Number 

Number 

Modifier 

Denotes design activity and/or 
manufacturing source. It is used 
with above contractor assigned 
numbers to assure unique 
identification. 


TABLE A 
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SPECIFICATION 

NUMBER 

- — 

DESCRIPTION OF EXAMPLE 

123456 

Specification draft for coordination 

123456A 

First formally approved issue of the 
same specification 

10-40b 

The second SCN sheet to a change 
affecting page 40 of specification 
123456A which was approved as SCN #10 

123456B 

Revised specification incorporating 
the first revision directed by a CCBD 

382159A 

i 

First formally approved addendum 
specification made from 123456B and 
to be maintained by SCN's and revisions 
independent of the parent specification 


TABLE B 

EXAMPLES OF SPECIFICATION IDENTIFICATION NUMBERS 
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CONSTRUCTION OF THE CLASS I 


CHANGE IDENTIFICATION NUMBER 



Figure 2 
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REQUIREMENTS FOR CONFIGURATION 
IDENTIFICATION AND ACCEPTANCE OF 
CONTRACT END ITEMS AND 
RELATED DATA 
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REQUIREMENTS FOR CONFIGURATION 
ID ENTIFICATION AND ACCEPTANCE OF 
CONTRACT END ITEMS AND 
RELATED DATA 
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REQUIREMENTS FOR CONFIGURATION 
IDENTIFICATION AND ACCEPTANCE OF 
CONTRACT END ITEMS AND 
RELATED DATA 


1. PURPOSE 

This exhibit provides NASA and contractor organizations 
with requirements for identifying and interrelating contract 
end item equipments, facilities, spares, technical documents, 
and engineering data which are to be formally accepted by the 
procuring agency. 

2 . SCOPE 

This exhibit establishes requirements for identifying con- 
figuration at parts, component, subassembly and contract 
end item levels of assembly of systems/equipments. It estab- 
lishes the documentation relationship by which the identified 
configuration will be accepted as contract end items. This 
exhibit pertains to: 

a. Engineering specifications, drawings, lists and 
release records. 

b. Acceptance documents. 

c. Name plates and alternate means for the identifi- 
cation and marking of hardware and containers. 

d. Technical documents. 

3. APPLICABILITY 

This exhibit applies to contract end items and related 
documents which are to be formally accepted or approved by 
the procuring agency for systems programs or for any other 
use. It applies to all contracts with the procuring agency 
for these items and documents, and for systems engineering 
and/or system integration contracts involving these items 
and documents. Contractors to the procuring agency shall 
be responsible for the compliance of their subcontractors, 
vendors, and suppliers. 
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4. REFERENCE DOCUMENTS 

4 . 1 Applicable Documents 

The following documents of the exact issue shown, 
or part thereof as further described, form a part 
of this exhibit: 


Exhibit X 


MIL-STD-100A 1 October 1967 


"Requirements for 
Configuration Identi- 
fication Numbers" 

"Engineering Drawing 
Practices" 


MIL-STD-129D 


28 December 1964 "Marking for Shipment 

and Storage" 


MIL-STD-130C 


29 September 1967 "Identification Mark- 
ing of U.S. Military 
Property" 


MIL-STD-480 30 October 1968 


"Configuration Con- 
trol - Engineering 
Changes, Deviations 
and Waivers" 


5. EXPLANATION OF TERMS 
(See Exhibit XVII.) 

6. PROCEDURAL REQUIREMENTS 

These procedures are based on the polices and practices 
of the procuring agency for configuration management. 

It is recommended that contractors review and understand 
these policies and practices as a part of implementing 
the procedural requirements in this exhibit. 

6 . 1 General Requirements 

Configuration shall be identified: 


a. At every level of assembly (piece parts 
through final assembly) . 
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b. On every deliverable item produced by the 
contractor and formally accepted by the 
procuring agency (i.e., equipments, facil- 
ities, spares, technical documents). 

c. By engineering drawings and specifications. 
These data, as approved and formally re- 
leased, shall be the source of all config- 
uration requirements for the production of 
all other deliverable products and docu- 
ments. 

d. At all times subsequent to formal accep- 
tance (through later testing, assembly, 
checkout, and operational usage to ulti- 
mate consumption) by proper update of 
engineering drawings and specifications 
to cover incorporated changes. 


The contractor shall identify configuration by 
the set of numbers defined in Exhibit X for use as 
applied in accordance with the procedural require- 
ments of this exhibit. Numbers other than those 
defined for use in Exhibit X shall not be used 
for configuration management. 

6 . 2 Implementation Requirements 

As part of implementing this exhibit, the con- 
tractor shall demonstrate to the procuring agency 
that he has adequate policies, organization and 
procedures for configuration management. 

6.2.1 Contractor Responsibilities . The respon- 
sibilities of the contractor for config- 
uration identification are: 

6. 2.1.1 To compose and assign all con- 
figuration identification num- 
bers in accordance with Ex- 
hibit X. 


6. 2.1. 2 To apply these numbers to doc- 
uments and equipments in accor- 
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dance with the requirements in 
this exhibit. 


6.2. 1.3 To continuously maintain the relationship 
and continuity between these documents and 
equipments so that the development and quali- 
fication of equipment, it f s production and 
logistic support will match engineering and 
contract requirements. 

6. 3 Engineering Drawings 

The contractor shall use MIL-STD-100 and its directly referenced 
documents, to completely identify configuration on drawings. 

6.3.1 Identification Numbers 


6. 3. 1.1 All standard configuration identification 
numbers shall be shown on engineering draw- 
ings or in engineering release records. 

6. 3. 1.2 All standard configuration identification 
numbers shall be on submitted engineering 
drawings and lists. 

6. 3. 1.3 The same drawings and configuration identi- 
fication numbers used for manufacture or 
construction of, and change to, deliverable 
equipments and facilities shall be used for 
the manufacture of spares and preparation of 
operations and maintenance manuals for these 
same equipments and facilities. 


6. 3. 1.4 These same drawings and identification num- 
bers shall be used for manufacturing addi- 
tional quantities of these same eauipments 
and facilities. 

6. 3.1.5 All drawings shall contain the code identi- 
fication number of the design activity for 
the drawing. 

6. 3. 1.6 Existing drawings shall not be revised to 
retroactively incorporate the identification 
requirements in Exhibit X. As existing draw- 
ings are re-released for a 1-and-on effecti- 
vity for a new contract end item type-model- 
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series, they shall be redressed to be in 
accordance with Exhibit X. 

6.3.2 Application Data . All production and construction 

drawings which together document the technical descrip- 
tion of a CEI shall be interrelated by drawing applica- 
tion data which may be entered on the drawings or in 
the engineering release records for the drawings, and 
will provide the information required in the following 
subparagraphs . 

6.3.2. 1 The "PART NO." created by the drawing for 
callout in the list of materials of the parts 
"NEXT ASSEMBLY." 

6.3.2 .2 The "NEXT ASSEMBLY" part number (s) of all 
immediate next assemblies of each "PART NO." 

6. 3. 2. 3 "REQ'D PER N/A" (Required Per Next Assembly) 
shall contain the total number of "PART NO." 
items required to make one of each "NEXT 
ASSEMBLY. " 

6. 3.2. 4 The "END ITEM NO." in which each "NEXT 
ASSEMBLY" is to be installed. 

6. 3. 2. 4.1 If the design activity is a sub- 
contractor, vendor or supplier 
whose end product is a sub- 
assembly part of the contractor's 
CEI, the "END ITEM NO." will be 
the top drawing number of his end 
product. 

6. 3.2.5, The "SERIAL NO." of the contract end items 
in which each "NEXT ASSEMBLY" is to be in- 
stalled. "X & UP" or "X & ON" notations shall 
be used. 

6. 3. 2. 5.1 If the design activity is a sub- 
contractor, vendor or supplier 
whose end product is a sub- 
assembly part of the contractor's 
CEI, the "SERIAL NO." will be the 
part number serialization assigned 
by the supplier within the top 
drawing number. 

NOTE: The procuring agency regular- 
ly accepts contract end items 
from one source and supplies 
them for installation in 
equipments to be supplied as 
a contract end item by ano- 
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ther source. An example 
is an engine supplied for 
installation in an aero- 
space vehicle. In these 
cases the installing con- 
tractor shall always identi- 
fy the supplied contract end 
item in the list of material 
of his drawing as Government- 
furnished. 

6, 3. 2.6 The top drawing or release record of a con- 
tractor’s CEI or of the end product of a sub- 
contractor, vendor or supplier shall contain 
no application data. 

6.3.3 Revision Block . All production and construction draw- 
ings shall contain a revision block in accordance with 
the format in MIL-STD-100 . This block shall be main- 
tained as follows: 

6. 3. 3.1 Up to the time of cutoff established by the 
contractor for changes to be incorporated 
prior to formal acceptance by the procuring 
agency of the first CEI in the type-model- 
series, the production or construction draw- 
ings shall be maintained by change letter 
control and drawing revisions noted in the 
revision block in accordance with standard 
practice. 

6. 3. 3. 2 At and subsecruent to this cutoff all drawing 
revisions shall be identified by a change 
identification number in addition to a draw- 
ing revision letter and date. This identi- 
fication shall be permanently retained even 
if the drawing is completely redrawn. 

6. 3. 3. 3 The "DESCRIPTION" column of the revision 
block shall identify the change identifica- 
tion number and relate it to the drawing 
revision letter as follows: 

6. 3. 3. 3.1 The contractor shall first enter 
the note "CLASS I" or CLASS II" 
to indicate the classification 
of the change in accordance with 
MIL-STD-480 (refer to Exhibits 
VIII and IX) . 
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6. 3. 3. 3.2 The contractor shall next enter 
the change identification number 
of the Class I or Class II change. 

6. 3. 3. 3. 3 The contractor shall then note 

any other pertinent revision letter 
data. 

6. 3. 3. 4 Drawings may be changed by an ancillary docu- 
ment of the drawing (e.g., an E.O. , ECN, etc.) 
rather than by drawing revision, in which case 
the ancillary document shall contain the data 
requi red in paragraphs 6 . 3 . 3 . 3 . 1 and 6 . 3 . 3 . 3 . 2 . 


6.3. 3. 4.1 When ancillary documents are in- 
corporated in the drawing, the data 
in paragraphs 6. 3. 3. 3.1 and 6. 3.3. 3. 2 
shail be transcribed and entered in 
the revision block of the drawing 
for the appropriate revision letter. 

6.3. 3.5 There may be more than one classified change 
per revision letter. There shall not be 
more than one revision for one classified 
change . 

6.3.4 List of Material . Vendor parts components and sub- 
assemblies, other than standards, shall normally be 
listed by vendor part number. Specification identifi- 
cation numbers shall be used only until the vendor part 
number is assigned and obtained. 

6. 3. 4.1 When more than one source can satisfy the 
design application, only one source shall be 
made a reouirement for the CEI unit that is 
FACI'd (refer to Fxhibit XIV), and all sub- 
sequent units, unless alternate sources are 
formally approved by the procuring agency. 

6. 3. 4.2 If an additional source is approved as an 
alternate and interchangeable, the item shall 
continue to be identified by one vendor draw- 
ing and part number accompanied by an alter- 
nate and interchangeable note referencing 
the other drawing and part number (s) and the 
governing specification identification number. 


6.3.5 


Top Drawings, Sites and. Interconnects . In configura- 
tion management, all production and construction draw- 
ings are part of some prime equipment item or identifi- 
cation item (see Table A) . All items shall have a top 
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drawing, shall be formally accepted by the procuring 
agency at the contractor’s plant or site of construc- 
tion, and shall be controlled thereafter as Government 
property. In system programs, this property is then 
installed in higher order contract end items which are 
also formally accepted. Lastly, the integrated instal- 
lation at each location is accepted and turned over to 
a using agency. 

6. 3.5.1 The contractor's top drawing for a contract 
end item shall define the configuration in 
which it may be removed and replaced for 
maintenance or modification. 

6. 3. 5.2 Loose equipment is a delivery condition. 
Knockdowns for shipment and kits of identi- 
fication items shall not be shown on produc- 
tion drawings. 

6. 3. 5. 3 Special shipping and storage containers shall 
be identified as prime eauipment items or 
identification items (see Table A) as deter- 
mined by their specifications. 

6. 3. 5. 4 Site construction shall be documented by a 
top drawing as a facility contract end item 
and shall be formally accepted by the pro- 
curing agency at the Beneficial Occupancy 
Date (B.O.D.j. Field runs shall be dimen- 
sioned to the extent required to control 
interfaces, provide clearance for future 
installations and data for replenishing 
spares . 

6. 3. 5. 5 Equipped facilities shall be a prime equip- 
ment contract end item consisting of the site 
after B.O.D. , installed GFE (accepted contract 
end items) , FPIE and interconnects (including 
accepted identification items, and/or parts 
called out as part of the facility top draw- 
ing) . 

6. 3. 5. 6 A complete complex or base shall be a prime 
equipment contract end item documented by a 
top drawing when required to call out inter- 
site cabling, splice-ins, conduit, etc. 


6.4 Equipment Identification Nameplates and Markings 


The contractor shall identify deliverable contract end item 
equipments, aerospace facilities and spares by nameplates and 
markings as recruired by this Section. Nameplates and markings 
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X 

shall be made and affixed in accordance with MIL-STD- 
130, and MIL-STD-129, or NASA equivalent, as supplemented 
and, in case of conflict, superseded by these instructions. 
All configuration identification information on these name- 
plates and markings shall be taken from and agree with pro- 
duction or construction drawings and/or their engineering 
release records. 


6.4.1 Contract End Items (CEI's). The contractor shall 

identify each deliverable contract end item unit with 
a nameplate arranged as shown in Figure 1 and contain- 
ing the information shown thereon. CEI nameplates 
shall be located for convenient examination by service 
and operating crews when the CEI is in an operational- 
ly ready position. 


6.4.2 


Engineering Critical Components . The contractor shall iden- 
tify each engineering critical component with a nameplate 
arranged as shown in Figure land containing the in^ 
formation shown thereon except : 


6. 4.2.1 Note 1 "Leave blank." 


6. 4.2.2 Note 2 shall be the part serial number (not 
the CEI serial number) . 


6. 4.2.3 Note 3 shall be the part number of the criti- 
cal component (not the CEI part number) . 


6. 4.2. 4 Note 4 shall be the specification and revi- 
sion number of the critical component speci- 
fication (not the CEI Detail Specification 
and revision number) . 


6.4.3 Identification Items . The contractor shall identify 
each identification item (see Table A) by a nameplate 
or equivalent containing the "CONFIGURATION IDENTIFI- 
CATION" data shown in Figure 1, notes (1) through (6). 


6.4.4 Requirement Items . Requirement items (see Table A) are 
GFE . The contractor shall re-identify GFE only as re- 
quired by Modification Instructions which he accomplishes 
and logs in historical records supplied with the GFE. 

When a requirement item is altered or selected by a 
contractor it shall be identified as a contract end 
item by the contractor in accordance with paragraph 
6.4.1 or 6.4.3, or as a part thereof. 


Minimum Marking Requirements for CEI 1 s and Components . 
The contractor shall mark CEI * s and critical components , 
which are too small for complete identification, with 
the following minimum configuration data: 
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6. 4.5.1 The part number. 

' '*•* 61 4;. 5.2 The serial number. 

-* 6. 4; 5. 3 * The design activity code identification num- 
ber, and the manufacturer's code identifi- 
cation number, if different. 

6.4.6 Serialization . The contractor shall serialize all con- 
tract end items and critical components. Other parts 
and assemblies may be serialized at the contractor's 
' ; • option. 

6.4.7' Parts and Standards . The contractor shall mark all 

parts and company standards with their part number or 
standard specification identification number, serial 
number (if used) , the design activity code identifi- 
■ ' ‘ cation number, and the manufacturer's identification 

number code (if different). The contractor need not 
comply with this practice when: 

6. 4.7.1 The part is too small, or would be physi- 
cally or functionally damaged by this identi- 
fication. In this situation shipping con- 
tainers shall carrv the required identifi- 
cation, if used. 

6. 4.7.2 The part is encapsulated within another or 
otherwise permanently assembled and is not 
replaceable as a unit. 

6. 4.7.3 The part is a permanent part of a constructed 
facility. 

6.4.8 Shipping and Storage Containers . The contractor shall 
mark shipping and storage containers as required by 
MIL-STD- 12 9 , supplemented to include the "CONFIGURATION 
IDENTIFICATION" data shown in Figure 1 as defined in 
paraaraphs 6.4.1 through 6.4.7. 

6.5 T echnical Documents 

When Technical Documents (Operations and Maintenance Manuals, 
Modification Instructions, Illustrated. Parts Breakdowns, etc.) 
are required by the procuring agency the contractor shall insure 
that the following minimum requirements for relationship and 
identification are satisfied: 

a. The Technical Documents must relate to the engineering 
data' (specifications and .drawings) on which they are 

'■ based. 

b. The Technical Documents must identify the specific 
contract end item configuration (s) to which they 
apply. 
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c- The Technical Documents must cross reference changes 
or revisions to the approved engineering change pro- 
posal being incorporated in the contract end item. 


6.5*1. 


Operations and Maintenance Manuals . When different 
production configurations of a contract end item are 
to be accepted (as identified by the production incor- 
poration of Class I changes) , the contractor shall 
clearly organize the material in technical manuals so 
that they may readily be used to operate and maintain 
these different configurations. This capability shall 
be retained until full retrofit to a standard configu- 
ration has been accomplished. 


6.5.1. 1 


Configuration Chart . The contractor shall 
include a configuration chart, or equivalent 
display, in each operations and maintenance 
manual. .The function of the configuration 
chart is to relate the technical manual, its 
revisions and/or supplements to the configu- 
rations they describe and support. The 
recommended format should be similar to a 
chart used in specifications to document 
their revision status, and will therefore 
permit direct comparison with the revision 
status of a technical manual. The con- 
figuration chart shall be inserted immed- 
iately behind the title page. 



Formal acceptance by the procuring agency shall include all 
procedures and data necessary for inspection, testing or 
verification, and approval of contract end items, spares or 
other equipment or data requiring transfer of title to an 
authorized Government agency. 


6.6.1 Acceptance Requirements 

6. 6. 1.1 Acceptance testing will be conducted as 

specified in Part II of a CEI Specification 
to verify compliance with the functional re- 
quirements in the specification. 


6. 6. 1.2 Identification will be verified by inspection 
of nameplates or the title pages of Operations 
and Maintenance Manuals to assure correspon- 
dence with drawings. 


6. 6. 1.3 Certification shall be made by the contractor 
and verified by the procuring agency that the 
equipment has been manufactured to the appli- 
cable configuration required by engineering 
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drawings and specifications (refer to Exhi- 
bit XIII) . 

6. 6. 1.3.1 The specification for the item 
presented . f of acceptance shall be 
reconciled with the applicable 
approved engineering changes 
(ECP's) incorporated as a speci- 
fied requirement. 

6.6. 1.3.2 The specification for the accep- 
tance item shall be reviewed to 
ensure that. all waivers and/or 
deviations from the specification 
are approved and accepted by the 
procuring adency. 

6.6. 1.4 Shortages shall be Verified from engineering 
data and recorded on the acceptance document 
(see paragraph 6. 6. 1.8). 

6.6. 1.5 An equipment historical record will be pre- 
pared for each end item as a vehicle for 
recording the history of calendar or cyclic 
life components within the end item as well 
as for recording approved engineering changes 
incorporated in production (and later by 
retrofit) . 

6.6. 1.6 Technical Documents will be verified to the 
extent specified by the procuring agency, on 
the eouipment to which they are applicable, 
individually or as part of a system as appro- 
priate. 

6. 6. 1.7 Engineering data shall be provided by the 
contractor and will include the following as 
required within the applicable contract: 

6. 6. 1.7.1 An approved contract end item 
specification. 

6. 6. 1.7. 2 A complete set of released engi- 
neering drawings prepared in 
accordance with MIL-STD-100. 

6. 6. 1.7. 3 All applicable interface drawings 
and/or data with approval completed 
as directed by the procuring agency. 

6.6. 1.8 Every contract item accepted by NASA will be 
accepted by execution of a Material Acceptance 
and Receiving Report (DD Form 250 or equiva- 
lent) . 
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6. 6 .1.8.1 The DD-250 (or equivalent) shall 
identify, by serial number, all 
controlled subassemblies and/or 
requirement items within the prime 
end item. 


6. 6.1. 8.2 All shortages or other departures 
from contractual acceptance re- 
quirements will be included on 
the DD-250 (or equivalent). 


6.7 System Acceptance 


All equipments, facilities, spares, technical documents, and 
engineering data comprising a system shall be accepted in 
accordance with the foregoing paragraphs. System acceptance 
consists of successful completion of a test program as speci- 
fied in the system performance requirements design general 
specification. Each Apollo system programmed will undergo 
acceptance procedures in accordance with the preceding confi- 
guration documentation requirements. 
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TABLE A 

EQUIPMENT CATEGORIES 


CONTRACT END ITEMS 


EQUIPMENT REQUIREMENTS 

REQUIRE- 

MENT 

GEI's 

IDENTIFI- 
CATION 
CEI ' S 

PRIME 
EQUIPMENT 
CEI 1 s 

Equipment is supplied by 
contractor 

NO 

Yes 

Yes 

Contractor will prepare indivi- 
dual specifications for each 
CEI 

NO 

Yes 

Yes 

Major provisioning action 
required 

NO 

Yes 

Yes 

Contractor will prepare indivi- 
dual technical manuals for 
each CEI 

No 

No 

Yes 

100% acceptance testing re- 
quired 

No 

No 

Yes 

Engineering changes are ex- 
pected after item has been 
formally accepted 

No 

No 

Yes 


These items are GFE . 


These items are secondary support items 
delivered by the contractor. 


These items are prime items. They provide 
the basis for configuration control, 
including the control of Identification 
and Requirement CEI*s. 
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NOTES : 

1 CONTRACT END ITEM NUMBER 

2 CONTRACT END ITEM SERIAL NUMBER 

3 CONTRACT END ITEM PART NUMBER 

4 CONTRACT END ITEM DETAIL SPECIFICATION AND REVISION NUMBER 

5 DESIGN ACTIVITY CODE FROM CATALOGING HANDBOOK H4-1 

6 FEDERAL STOCK CLASS AND FEDERAL ITEM IDENTIFICATION NUMBER 

7 NOMENCLATURE 

8 MANUFACTURING CONTRACT NUMBER 

9 MANUFACTURER'S CODE FROM CATALOGING HANDBOOK H4-1 

10 MANUFACTURER'S COMPANY NAME 

11 GOVERNMENT OWNERSHIP SYMBOL 


SAMPLE CONTRACT END ITEM NAMEPLATE 
FIGURE 1 
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ENGINEERING RELEASE RECORD REQUIREMENTS 


1 . PURPOSE 

This Exhibit provides NASA and contractor organizations 
with the minimum requirements of the procuring agency for 
achieving proper relationships between identification 
elements in an engineering data file. 

2. SCOPE 

This exhibit establishes minimum requirements and 
capabilities to be provided by the contractor’s 
engineering release system pertaining to: 

a. Elements of data required. 

b. Contractor’s production release functional 
capabilities. 

c. Release of engineering changes. 

d. Contractor’s field release functional 
capabilities . 

The exhibit does not establish , or require the contractor 
to provide, standardized formats for an engineering 
release system. 

3. APPLICABILITY 

This exhibit is applicable to all contracts requiring 
submission of engineering data. Contractors to NASA 
shall be responsible for the compliance of their sub- 
contractors , vendors and suppliers . 

4. REFERENCE DOCUMENTS 

The following documents are referenced in the text of this 
exhibit for reference purposes only, and do not form a 
part of this exhibit: 

Exhibit X "Requirements for Configuration 

Identification Numbers.* 7 
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Exhibit XIV "Formal Configuration Management 

Reviews, Inspections and 
Demonstrations . " 


5. EXPLANATION OF TERMS 
See Exhibit XVII, 

6 . PROCEDURAL REQUIREMENTS 

6 . 1 General Requirements 

The contractor shall prepare and maintain engineering 
release records in accordance with his formats, systems, 
and procedures, and the minimum requirements in this 
exhibit. The contractor’s formats, systems, and procedures 
may include information in addition to these minimum 
requirements providing that the portion thereof which 
constitutes engineering release records: 

a. Is limited to an expression of configuration 
requirements defined by engineering data. 

b. Does not reflect a hardware or other product 
condition that varies from the engineering 
requirements contained in these data. 

c. Does not reflect manufacturing status. 

Only one release record (which may be multisheet) shall 
be maintained for each drawing number. Drawings released 
by a subcontractor, vendor, supplier, or another contractor 
shall not be re-released by the contractor. 

6 . 2 Elements of Data Required 


The contractor’s engineering release records shall contain 
the standard configuration identification numbers (refer 
to Exhibit X) and other elements of information listed 
in this subparagraph. 

6.2.1 Contract End Item (CEI) Elements : 

CEI Number. 

CEI Serial Numbers. 

Top Drawing Number. 

CEI Specification Identification Number. 

6.2.2 Drawing Elements : 
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Drawing Number, 

Drawing Title. 

Code Identification Number 
Number of Sheets. 

Date of Release. 

Change Letters . 

Date of Change Letter Release. 

Ancillary Document Numbers (ECNs, E.O.s, 

Variations , etc.) . 

Specification Document, Specification Control 
Drawing or Source Control Drawing Number. 

6.2.3 Part Number Elements 

Controlling Drawing Number. 

Part Numbers Released. 

Change Letter which created Part Number. 

Change Identification Number which created Part 
Number. 

6 . 3 Contractor's Production Release Functional Capabilities 

To the extent that the contractor has detail design 
responsibility, the contractor's release function and 
documentation, including drawings and associated lists, 
shall be capable of determining these released engineering 
requirements : 

6.3.1 The composition of any part number at any Llevel 
in terms of subordinate part numbers , except 
for standard parts. 

6.3.2 All next higher using (next assembly) part 
numbers of any part, except for parts assembling 
into standard parts. 

6.3.3 The composition of any CEI in terms of part 
numbers and subordinate CEI numbers. 
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6.3.4 The CEI number and CEI serial numbers 

(ef fectivity) on which any subordinate part is 
used. This does not apply to subcontractors, 
vendors, and suppliers who , are not producing 
CEIs . 

6.3.5 The Class I and Class II Change Identification 
Numbers, which have been partially or completely 
released for any CEI Number and CEI Serial Number. 

6.3.6 The CEI numbers and CEI serial numbers, which 
constitute the effectivity- of any change 
identification number. 

6.3.7 The Class I and Class II change identification 
numbers , which have been partially or\ completely 
released for any part number.. r '3 

6.3.8 The standard specification numbers or standard part 
^numbers used within any non-standard part number. 

6.3.9 The subcontractor, vendor, or supplier part 
numbers which have been assigned in response to 
critical component specification documents, 
specification control drawings, or source control 
drawings issued by. the contractor. 

6.3.10 The : contractor's specification document, 

specification control drawings, or source control 
drawing numbers associated with any sub con tractor, 
vendor or supplier part number. 

6.4 Release of Engineering Changes . 

The contractor's release function and documentation shall 
be capable of identifying engineering changes, and of 
retaining the record of superseded configuration re- 
quirements , affecting item$ which have been, formally 
accepted by the procuring agency. - r ' • 

6.4.1 All Class I and Class II engineering changes 

released for production incorporation shall be 
identified by change identification numbers and 
shall be completely released prior to formal 
acceptance of the CEI unit where first installed. 

6. 4. 1.1 The configuration released for 

each CEI unit at the time of its formal 
acceptance shall be retained in release 
records for the time required by re- 
tention of records requirements in the 
contract, or as outherwise provided in 
paragraphs 6.5 through 6.5.3. 
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6.4,2 All engineering design released for in- 
corporation in any CEI which has been 
formally accepted shall be identified 
by change identification numbers which 
are different than those assigned in 
accordance with paragraph 6.4.1, above. 

6 . 5 Contractor’s Field Release Functional Capabilities 

Engineering data defining formally accepted equipment 
which is under the jurisdiction of the contractor, 
and which is progressing through testing or through 
activation programs, shall be maintained current 
with all field activity requirements and released 
as follows: 

6.5.1 Superseded requirements may be replaced by 
superseding requirements in the release records 
for formally accepted units of a CEI type, 
model, series which are supported by the 
contractor and which were accepted prior to 
the FACI (refer to exhibit XIV) of the CEI 
type, model, series; i.e., at the contractor's 
option, superseded requirements need not be 
retained in the release record for these 
units. 

6.5.2 After FACI, superseded requirements shall 
be retained (as a reference release) and 
superseding requirements added (as a requirements 
release) in the release records for all units of 
the CEI which have been formally accepted and 
are under the jurisdiction of the contractor; 
i.e., the multiple release procedure shall be 
used. 

6. 5. 2.1 Superseded requirements shall be retained 
in multiple release records until status 
accounting records indicate superseded 
configurations are no longer in inventory. 

6.5.3 Engineering changes to CEIs which have been formally 
accepted by the procuring agency, and which are 

not under the jurisdiction of the contractor, 
shall be released for service action; i.e., the 
multiple release procedure shall not be used. 
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REQUIREMENTS FOR VERIFYING THE 
INCORPORATION OF CLASS I ENGINEERING CHANGES 


1. PURPOSE 

This Exhibit provides NASA Apollo organizations and 
contractors with requirements and guidance for in- 
specting and recording the incorporation of Class I 
engineering changes in deliverable contract end items , 
vendor items and subassemblies which are part of 
contract end items. 

2. SCOPE 

The requirements in this Exhibit identify the contractor 
capabilities necessary to control internally the in- 
corporation of Class I engineering changes (hereafter 
referenced to as "engineering change") in contract end 
items. The contractor's internal system of controls 
shall be capable of: 

a. Reconciling engineering work authorizations 
to contract requirements. 

b. . Verifying that released engineering and 

purchase order data are in accordance with 
contract requirements. 

c. Assuring that engineering changes are manu- 
factured and installed as required for formal 
acceptance. 

d. Documenting engineering change incorporation 
as required for formal acceptance. 

3. APPLICABILITY 

This Exhibit applies to all contracts with NASA for de- 
liverable manufactured products. 

4. REFERENCE DOCUMENTS 

The following documents of the exact issue shown, or 
part thereof as further described, for a part of this 
exhibit: 

NHB 5300. 4 (IB) . April 1962 


NPC 200-3 April 1962 


"Quality Provisions 
for Aeronautical and 
Space System Contractors." 

"Inspection System Pro- 
vision for Suppliers of 
Space Materials, Parts, 
Components, and Services" 
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Exhibit VII 
Exhibit IX 


Exhibit XI 


Exhibit XII 


Exhibit XIV 


5. EXPLANATION OF TERMS 
(See Exhibit XVII) . 

6. PROCEDURAL REQUIREMENTS 

It is Apollo Program policy that each engineering change will be 

incorporated in all units within one type-model-series 

of the contract end item affected. Complete verification 

of the incorporation of engineering changes is required 

to assure that retrofit kits and spares will be ordered 

and shipped to the proper location. The requirements of 

this exhibit are based on manufacturing and quality 

control capabilities which the contractor must possess 

if he is to successfully contract with the Government, 

and comply with the requirements in NHB 5300.4 (IB) or 

NPC 200-3 as applicable to his contract. 

6 . 1 Verification Requirements 

Contractual authorization is required by the contractor 
to design, manufacture and install engineering changes. 

The contractor shall control the design, manufacture 
and installation of each engineering change as directed 
by contract. 

6.1.1 Contract Reconciliation . The contractor shall 
assure that his E CP has been prepared in ac- 
cordance with Exhibit IX, and that the ECP 
and other engineering work authorizations are 
in accordance with contractual authority. 


"Specification Maintenance . M 

"Preparation of Engineering 
Change Proposals for Contract 
End Items." 

"Requirements for Configuration 
Identification and Acceptance 
of Contract End Items and Related 
Data." 

"Engineering Release Record Re- 
quirements. " 

"Formal Configuration Management 
Reviews, Inspections, and De- 
monstrations . " 
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6.1.2 Technical Verification . The contractor shall 

verify by an engineering release record (having 
the capabilities required by Exhibit XII) that the 
ef fectivities of all engineering data for a 
Class I engineering change are compatible with 
contractual authorizations which approved and 
authorized the change. 

The contractor shall also verify that: 

6. 1.2.1 The engineering release includes 
the release of a final Specification 
Change Notice (SCN) or revision 

as approved with the ECP specification, 
(refer to Exhibit VII.) 

6. 1.2. 2 No qualification requirements are 
established or changed by engineering 
data unless specifically authorized 
by contract and/or contract change. 

6. 1.2. 3 Any changes in acceptance test re- 
quirements have been converted to 
procedures, and that these pro- 
cedures are within the specifications, 
schedules, and costs authorized by 
contract and/or contract change . 

6. 1.2. 4 Vendor purchase orders and change 
notices are in accordance with 
specifications, schedules and 
costs authorized by contract and/ 
or contract change. 

6. 1.2. 5 Manufacturing requirements are in 
accordance with the specifications, 
schedules and costs authorized by 
contract and/or contract change. 

Note: Any revision in previously 

approved specifications, 
effectivity , delivery 
schedule or increase in 
cost will require prior 
approval of the procuring 
agency before proceeding 
with production. 


Production Capability Requirements. 


The contractor shall verify that all contract end 
items are manufactured in accordance with released 
engineering data by assuring that: 
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6.2.1 Part Numbers are not changed except as required 

by approved and released engineering data which have 
identified a non-in terchangeable condition. 

6.2.2 Synthetic numbers or codes are either clearly 
marked "Manufacturing Designation Only," or 
are removed before acceptance of equipment by 
NASA. 

6.2.3 Material controls are capable of verifying that 
any specific engineering changes which are re- 
quired as a result of the Class I change have 
been incorporated in specific units of either 
interchangeable or non-in terchangeable vendor items. 

6.2.4 Manufacturing controls are capable of identifying 
the specific engineering changes which have been 
incorporated in specific units of either inter- 
changeable or non-interchangeable "bench" and 
lot produced sub-assemblies. 

6.2.5 Manufacturing controls are established to 
properly route vendor items and slab-assemblies 
containing engineering changes to the contract 
end items on which these engineering changes 
are to be installed as k .required by released 
engineering data. 

6 . 3 Inpsection, Audit and Surveillance 

The contractor's quality control function, independent 

of his technical and production functions, shall: 

6.3.1 Audit manufacturing orders as required to verify 
complete conversion of engineering data for each 
engineering change to shop action exactly as re- 
leased and assure that the manufacturing and quality 
control documentation used by the contractor is 
auditable to released engineering data. 

6.3.2 Inspect material control, manufacturing control and 
assembly operations (as described in paragraph 6.2) 
and verify that each change is completely incorporated 
in the contract end item unit for which it first 
applies or that any missing part of the change is 
listed as a shortage. 

6.3.3 Verify that the requirements for subsequent 
incorporations of each change are contained in pro- 
duction orders; that routine material and man- 
ufacturing controls will suffice to assure that 
these installations will be accomplished as re- 
quired by released engineering, or will be shown 

as shortages. 
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6,3.4 Maintain an adequate surveillance in accordance 
with approved standard practices to assure the 
proper incorporation and documentation of sub- 
sequent installations of each engineering change. 

6 . 4 Documentation of Incorporated Engineering Changes 

The contractor shall maintain engineering change in- 
corporation records, provided by his internal system 
of controls having the capabilities described by the 
subparagraphs below: 

6.4.1 An inspection file showing, by an inspector's 
acceptance of shop travellers, receiving reports, 
etc., the part numbers and serial numbers man- 
ufactured which are on the contract end item 
unit where each engineering change is first 
installed. 

6.4.2 A record for each contract end item unit in which 
an engineering change is first installed. This 
record shall show that the required subassemblies, 
by part number and serial number, were installed. 

CAUTION: The level of assembly where an 

engineering change is installed and 
related to a particular contract 
end item unit may be above the level 
of assembly where interchangeability 
was reestablished. Therefore, part 
number identification, alone, will 
not verify that a change has been 
incorporated. 

6.4.3 A Break of Inspection (BOI) record for each contract 
end item unit to document any demodification actions 
resulting from removals and replacements after the 
initial installation has been accepted by the 
inspector. 

6.4.4 A shortage report for each contract end item unit 
to record any part of any engineering change which 
has not been installed 

6 . 5 NASA Acceptance 

NASA acceptance of contract end items will be accomplished 
at the contractor's plant (or site of construction in the 
case of facilities) in accordance with: 

6.5.1 The terms and conditions of the contract. 

6.5.2 The requirements for formal identification and 
acceptance (see Exhibit XI) . 
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6.5.3 Formal agreements reached at previous 
Configuration Management reviews and 
demonstrations (see Exhibit XIV) . 

6.5.4 The contractor’s inspection acceptance 
files. Change Incorporation Records (CIR's) , 
BOI’s and shortage reports as reconciled 

at the time of acceptance. 
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FORMAL CONFIGURATION MANAGEMENT 
REVIEWS , INSPECTIONS AND DEMONSTRATIONS 


1 . PURPOSE 

This exhibit provides NASA and contractor organizations 
with the objectives of joint contractor/procuring agency 
formal configuration management reviews and inspections 
and defines contractor tasks and responsibilities 
associated with these reviews, demonstrations and in- 
spections . 

2 . SCOPE 

This exhibit defines the product of each of the reviews 
related to configuration management. The three important 
reviews associated with configuration management are the 
Preliminary Design Review (PDR) , the Critical Design 
Review (CDR) , and the First Article Configuration In- 
spection (FACI) . 

3. APPLICABILITY 

This exhibit is applicable to NASA MSF Centers and contractors 
responsible for the accomplishment of configuration management 
reviews . 

4. REFERENCE DOCUMENTS 
None 

5. EXPLANATION OF TERMS 
See Exhibit XVII 

6. PROCEDURAL REQUIREMENTS 

The administrative aspects of the Preliminary Design Review, 
Critical Design Review and First Article Configuration In- 
spection are common. The following paragraphs establish 
responsibilities for the organization, representation 
and conduct of these reviews, and the basic policy 
which shall govern the output/products of these reviews. 

It is emphasized that other reviews may be performed during 
any phase of the program at the discretion of NASA. By 
mutual agreement of the procuring agency and the contractor, 
the review of several CEI ' s may be accomplished at a single 
review. Representatives of contractors responsible for the 
design /development of equipment/facilties which interface with 
the CEI in review may participate in the review. Par- 
ticipation in a review or acceptance of a report of a review 
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by representatives of the procuring agency shall not be 
interpreted as approval of the design approach for or 
acceptance of the CEI . The representatives of the pro- 
curing agency designated to participate in the review 
or accept reports shall submit a formal report to the 
Project Director stating recommendations for post- 
review action. Normally, all reviews shall be ac- 
complished at the contractor's facility. 

6 . 1 Procuring Agency Responsibilities 

The Procuring Agency is responsible for conducting 
each review and shall: 

a. Establish the time, place and agenda for each 
review. 

b. Chair each review. 

c. Schedule a PDR, CDR, and FACI for each contract 
end item (categorized as either prime equipment 
items or identification items) . 

d. Formally acknowledge the accomplishment of each 
review and formally notify the contractor of 
requirements for post-review action. 

6 . 2 Contractor Responsibilities 

The contractor will participate in each review and 
shall: 

a. Have available all end items and associated 
documentation required for performance of the 
review. 

b. Prepare and distribute minutes of each review 
to the procuring agency. 

6 . 3 Conducting Preliminary Design Review 

The Preliminary Design Review is a formal technical 
review of the basic desiqn approach for a contract 
end item..- The PDR is accomplished prior to, or 
very early in, the detail design phase to establish 
the system compatibility of the design approach. 

The primary product of a preliminary design review 
is formal identification of specific engineering 
documentation which establishes the physical and 
functional interface relationship of the CEI to 
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other system tor inventory) equipment/facilities. 

Prior to the preliminary design review , the inter- 
face relationship of the CEI to other system (or 
inventory) equipment/facilities shall be established 
to the level of detail necessary to identify the 
nature of each interface. The schedule for the 
origination of detailed interface control drawings 
shall be established at the preliminary design 
review. The PDR shall be accomplished when the 
basic design approach has been selected by the 
contractor and preliminary documentation has been 
accomplished. The specific documeraentation to 
be reviewed, and detail action to be accomplished, 
at a given PDR shall be determined by the procuring 
agency at the time the agenda for the review is 
established. The following shall be accomplished 
as a part of each PDR: 

a. The compatibility of the selected design 
approach with Part I of the detail spec- 
ification for the CEI shall be established. 

b. The compatibility of the CEI with other system 
equipment/facilities shall be established. 

This shall be accomplished by review of pre- 
design drawings, schematic diagrams, layout 
drawings, envelope drawings, inboard profiles, 
review of performance characteristics for 
functional compatibility, etc. Since system 
engineering will be accomplished, system com- 
patibility of the CEI shall be established 

by review of the schematic block diagrams, 
functional block diagrams and other system 
engineering documentation. 

c. . The integrity of the selected design approach 

shall be established. This shall be accomplished 
by review of analyses, breadboard models, mockups, 
circuit logic diagrams, packaging techniques, etc. 
This is accomplished by the contractor as the 
basis for selection of the design approach presented 

d. The parts of the design to be subjected to detailed 
value engineering analysis shall be identified. 

e. The producibility cf the selected design shall be 
established. This shall be accomplished by review 
of requirements for special tools and facilities 
necessary to manufacture the CEI in the quantities 
required. 
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6 . 4 Conducting Critical Design Review 

The Critical Design Review is a formal technical 
review of the design of a contract end item (CEI) . 

The CDR is accomplished when the detail design is 
essentially complete, to formally establish the 
design as the basis for supporting activities, e.g., 
preparation of spares selection documentation, 
preparation of technical data, etc. The primary 
product of the CDR is formal identification of 
specific engineering documentation, which defines 
the design of the CEI, and which will be released 
for manufacture of the unit which establishes the 
product configuration baseline ("First Article" or 
equivalent) . The engineering documentation identified 
by the review, and updated until first, article con- 
figuration inspection, shall be the basis for sup- 
porting activities which must precede acceptance of the 
first article which normally occurs at the first article 
configuration inspection. Prior to the CDR, the 
exact interface relationship of the CEI to other 
system (or inventory) equipment/facilities shall 
be established, and shall appear on approved 
interface drawings which fix the physical inter- 
faces for the CEI, or in approved engineering 
documentation which fix the functional interfaces 
for the CEI. The CDR shall be accomplished 
immediately prior to committing the design to 
manufacture of the unit which established the 
product configuration baseline (First Article) . 

The specific documents to be reviewed, and 
action to be accomplished, at a given CDR shall 
be determined by the procuring agency at the 
time the agenda for the review is established. 

The following shall be accomplished as part 
of each CDR: 

a. The compatibility of the CEI, as designed, 
with Part I of the detail specification for 
the CEI shall be established. 

b. The system compatibility of the completed 
design shall be established. This shall be 
accomplished by comparison of the interface 
control drawings with the engineering drawings 
for the CEI. Since system engineering or 
functional analysis will be accomplished, schematic 
block diagrams, functional block diagrams, and 
other system engineering documentation shall be 
used to support the interface control drawings 

in establishing system compatibility of the CEI. 
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c. The integrity of the design shall be established 
by review of analytical and test data. By 
mutual agreement of the procuring agency and 
the contractor, the critical design review of 
several CEI ' s may be accomplished at a single 
review meeting. Representatives of contractors 
responsible for the design/development of equipment/ 
facilities which interface with the CEI in review 
may participate in the CDR. 

6.5 CONDUCTING FIRST ARTICLE CONFIGURATION INSPECTION 

The First Article Configuration Inspection is a formal 
technical review to establish the Product Configuration 
Baseline for the CEI. The primary objectives of a FACI 
are to formally accept the Part II CEI detail specification 
as an audited and approved document, to establish the 
similarity between the manufactured hardware and the re- 
leased engineering and identify the differences and to 
establish a precisely known baseline against which changes 
may be proposed and adequately evaluated. FACI f s are 
to be performed without regard to whether it will 
perform its intended function. At this point in time 
the primary concern is to determine if the item 
has been built to released engineering and tested to 
approved documentation. In the event the item is 
found to be incompatible or not capable of being used 
as originally intended through other associated test 
programs, (ie. Qualification Test, Environmental Test, 
Integrated System Test, etc.) or in actual use, the FACI 
is the firm baseline for evaluating change proposals. 

During the FACI it is important to perform an 
examination and review of the contractors engineering, 
manufacturing and quality assurance methods, disciplines, 
and documentation to insure that; 

a. Engineering 

1. Specification, drawings and part numbers comply 
with this document and Center supplements. 

2. Drawings are checked and approved prior 
to release to manufacturing. 

3. Drawing release system is adequate. 

4. E.O.'s are handled like drawings, and drawings 

N incorporate E.O.'s on a timely basis. 
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b. Manufacturing 

1. Changes cannot be incorporated independently of 
engineering. 

2. Planning paper, job sheets, travelers etc. 
reflect only released engineering, approved 
production methods and processes. 

3. Blueprint cribs have the latest released 
engineering on file. 

4. Hardware "as built" is in fact identical to 
"as released" engineering. 

c. Quality Assurance 

1. "In process" inspection steps are adequate 
and any steps requiring inspection are 
verified. 

s' 

2. All inspections are accomplished against 
released engineering. 

3. Issuance of inspector stamps are rigidly 
controlled. 

4. Accomplishment of tests against the Part II 
specification are validated and test results 
certified. 

Part II of the CEI detail specification, once audited and 
accepted at the FACI, serves as the basic documentation for 
configuration management of the CEI for the remainder of the 
acquisition phase. All changes to the CEI, once the FACI has 
been accomplished, shall be implemented only to reflect approved 
changes to Part II of the CEI detail specification. A major 
engineering change (new type-itDdel” se *ifcs) , or an indication 
that the configuration being produced does not accurately 
reflect released engineering, may require reaccomplishment 
of the complete FACI. The specific documen Nation and hard- 
ware to be reviewed and detail actions to be accomplished 
at the time the agenda for the review is established. The 
following shall be accomplished as a part of each FACI: 

a. The configuration of a selected Unit of the CEI, 
as documented by released engineering, shall be 
compared directly with the as-manufactured con- 
figuration of the same unit, as documented by 
part numbers and serial numbers appearing on the 
manufactured parts and assemblies, and in man- 
ufacturing records. When necessary, the as- 
manufactured parts shall be compared directly 
with the engineering drawing. The released 
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engineering for the selected unit shall be the 
drawings and documents assembled by the top 
drawing number specified in Part II of the 
CEI detail specification. Differences between 
the Configuration specified in Part II of the 
CEI specification and the as-manufactured 
configuration presented for review shall be 
documented on the DD Form 250 "Material Inspec- 
tion and Receiving Report" (or NASA equivalent) . 

b. The configuration of the CEI qualified (or to be 
qualified) , as documented by released engineering 
and/or manufacturing records, shall be directly 
compared to the configuration of the unit of the 
CEI FACI'ed, as documented by released engineering 
and/or manufacturing records. Differences be- 
tween the configuration of the CEI qualified and the 
CEI FACI'ed shall be made a matter of record in the 
minutes of the FACI. (The unit qualified should be 
identical to the unit FACI'ed modified only to per- 
mit installation of instrumentation if required.) 

c. The validity of acceptance testing, as specified in 
Part II of the CEI detail specification, shall be 
verified by direct comparison of the test method and 
test data with the performance/design requirements 
for the CEI. The comparison shall be accomplished 
to the level of detail necessary to establish that 
the methods and instrument readings, as required 

by the contractors internal test procedures, 
satisfy Part II of the detail specification and 
are adequate to verify the quality of the CEI. 

If changes to the acceptance testing as specified 
in Part II of the detail specif ication prove to be 
necessary, the specification change notice shall 
be prepared and a copy attached to the minutes of 
the FACI. The formal specification change shall 
be processed through normal procedure. 

d. Where the procuring agency has ordered delivery of 
engineering drawings of the CEI, the initial submittal 
of these drawings shall be those audited at the FACI, 
or later revisions of those audited at the FACI. 
Drawings to be used at the FACI should have all 
approved changes incorporated. 

e. Where the procuring agency has ordered delivery of 
specific records of the baseline configuration of 
the CEI, e.g., entries to be forwarded for inclusion 
in a system configuration index, such data shall be 
audited by direct comparison with released engineering. 
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f. If circumstances warrant, the contractors engineering 
release system and change control procedures shall 
be reviewed and validated. The procuring agency 
reserves the prerogative to reaccomplish all or any 
portion of the required audits, inspections and 
tests. Procuring agency action to accept or 
reject the unit of the CEI presented for FACI 
will be accomplished by the appropriate agency in 
accordance with normal acceptance procedures. 

The procuring agency will forward to the Contractor 
a FACI report summarizing the results of the in- 
spection . 
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CONFIGURATION MANAGEMENT AUDITS 


1. PURPOSE 

Configuration Management Audits may be ordered by the 
procuring agency at any time or place to verify the 
adequacy of Configuration Management procedures and 
implementation as practiced by NASA and contractor 
organizations, and to determine needed corrective action. 

2 . SCOPE 

This exhibit provides NASA and contractor organizations with 
requirements and responsibilities for the conduct and the 
product of Configuration Management Audits. Although it is 
directed towards the surveillance of major program elements, 
it does not preclude or usurp center or contractor authority 
to conduct comparable audits for lesser program elements. 

3. REFERENCE DOCUMENTS 
None 

4. EXPLANATION OF TERMS 
See Exhibit XVII 

5. PROCEDURAL REQUIREMENTS AND RESPONSIBILITIES 

The following paragraphs define the requirements and establish 
the policies and responsibilities for Configuration Management 
Audits. They will establish an organized, systematic approach 
to adequate audits in consonance with NASA and Apollo Program 
Documentation . 

5 .1 Policies 

The Apollo Program Office Configuration Management Office 
(CMO) or the Center Program Office CMO, as appropriate, 
will be responsible for the establishment of policies, the 
assignment of responsibilities, and the development and 
implementation of procedures for Configuration Management 
audits in their respective areas of interest. In general, 
the Apollo Program Office CMO will conduct audits of Center 
Configuration Management systems while the Center Program 
Office CMO * s will conduct audits at Project and Contractor 
level. This does not preclude the Apollo Program Office 
from conducting a configuration management audit at Project 
or Contractor level when warranted. 

5.2 Organization 

The appropriate CMO will be responsible for the determina- 
tion of the need for an audit and for the organization of 
the audit team. 
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5 . 3 Representation 

The responsible CMO will designate a chairman for 
each audit team. The team chairman will appoint other 
personnel to the team from APO, NASA Center, or 
supporting contractor organizations as may be 
appropriate. 

5. 4 Planning 


The team chairman will be responsible for development, 
release, and distribution of a detailed plan and agenda 
for the conduct of each Configuration Management Audit. 

5.4.1 A preliminary meeting of the audit team members 
shall be called as directed by the Team Chair- 
man. All personnel having an interest in or 
possessing pertinent knowledge of the audit 
subject shall be invited to attend this preliminary 
meeting. At this preliminary meeting, the 
following activities shall be performed: 

a. Discussion of the purpose, needs and causes 
that initiated the audit action. 

b. Perform a breakdown of audit elements and 
assign individual responsibilities to the 
team members by the chairman. 

c. Evaluate the scope of the audit, manhours 
available, and establish time schedules 
for performance of pre-audit actions and 
the audit itself. 

5.4.2 An individual review shall be performed by 
each team member of background data and in- 
formation concerning his assigned element (s) 
of responsibility. This review shall include 
the compilation of specific information and 
audit plan details to be used in the performance 
of the audit. 

5.4.3 A pre-audit meeting of the team members shall 
be called by the chairman after completion of 
the individual reviews and prior to "audit 
notification." At this meeting, plans will 
be finalized concerning the pending audit. 

All pertinent data which may significantly 
affect schedule, elements of the audit, facilities, 
personnel, etc., shall be presented at this 
meeting for discussion and resolution or decision. 
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5.4.4 The final draft of the audit plan will 
be made available to all members of the 
team and to supporting organizations at 
the time of audit notification. 

5 . 5 Audit Scheduling and Notification 


A Configuration Management Audit will be scheduled 
for each major program and contractor. Audits of 
lesser program elements may be directed and scheduled 
by the Apollo Program Office CMO or Center Program 
Office CMO where a problem is known or suspected to 
exist . 

5.5.1 A master audit schedule will be established 
by the responsible CMO. This schedule will 
be updated as required. 

5.5.2 Once the plans for conducting the audit are 
complete, notification shall be made to the 
affected parties at least thirty days prior 
to the audit. The notification will be made 
by the Chairman of the audit team. The 
notification shall include the following as 
applicable: 

a. Audit subject 

b. Inclusive dates of audit 

c. Audit team members 

d. Site of audit 

e. Copy of the audit plan 

f. Request for conference room space, 
organizational charts, documentation, 
telephone facilities, etc. 

5.6 Conduct of the Audit 


The audit shall be conducted in accordance with 
the following: 

5.6.1 Conduct a pre-audit conference at which 
team members will meet with appropriate 
personnel at the site. The team chairman 
will explain all objectives, plans 
procedures, responsibilities, and personnel 
area assignments of the evaluation for the 
understanding of all concerned. 

5.6.2 Conduct the audit utilizing this manual and 
other applicable documents. 
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5.6.3 Conduct a daily meeting of all participating 
parties, or individuals, as the chairman sees 
fit, at the end of each day to review the day's 
activities, adjust schedules as needed, and 

to coordinate the following day's activities. 

5.6.4 Consolidate daily results in preparation 
for exit critique. 

5.6.5 Conduct exit critique with center personnel, 
and discuss the preliminary results of the 
evaluation. The center personnel should be 
given an opportunity to explain any unusual 
or discrepant information obtained. This 
critique will normally be held the day 
following completion of the audit and will 
continue until the team chairman signifies 
adjournment. 

5 . 7 Audit records and Reports 

Each team member shall be responsible for providing 
and maintaining accurate records of conditions found 
within his assigned area. 

5.7.1 A preliminary report which summarizes findings 
shall be presented to the team chairman by 
each team member prior to the exit critique. 

This report should contain an accurate description 
of individual non-conformances in sufficient 
detail as to provide conclusive evidence of 
the existing situation. These preliminary 
reports should be the basis for discussion 
during the exit critique. 

5. 7. 1.1 Findings should be worked in the 

following format: 

a# Finding : A statement of the fact(s) 
identifying the particular problem 
area without embellishment. 

b. Determination : Based upon data 
available, an analysis is made 
and conclusions are drawn. 

c. Recommendation® : Corrective action (s) 
required at the center or its field 
operation . 
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5.7.2 Maintenance of minutes will be the 
responsibility of the audit team 
chairman. This responsibility en- 
compasses all official gatherings 

of audit personnel, and specifically, 
the preliminary meeting, pre-audit 
meeting, pre-audit conference, daily 
audit meetings, and exit critique. 

5.7.3 A final audit report will be prepared by 
the team and published as soon as practical 
after the conclusion of the audit. This 
report shall be a consolidation' of the 
preliminary reports submitted by the 

team members and a summarization of 
minutes of meetings. This report will 
contain a complete description of audit 
actions using the following elements as 
an organizational guide: 

i. Contents 
ii. Summary 

I . General 

a. Audit Title 

b. Participating Organization 

c. Audit Subject 

d. Audit Site 

e. Inclusive dates of audit 

f. Participating Personnel 

II. Introduction 

a. Reasons for audit 

b. Objectives and scope 

c. Background Information 

III. Planning 

a. Selection of Team 

b. Preliminary Meeting 

IV. Performance 

a. Areas of Investigation 

b. Preliminary Meeting 

V. Conclusions 

a. Items recorded for information only 

b. Action Items reported 

1. Items corrected during audit 

2. Items for which formal corrective 
action is (has been) requested. 

c. Corrective action responsibilities 
and assignments 
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5.7.4 The Apollo Program Office CMO will 
assign an appropriate identifying 
number to the audit report. 

5.7.5 The audit team chairman will transmit 
copies of all final audit reports to 
appropriate center , and Apollo Program 
Office (OMSF) personnel. 

5 . 8 Audit Follow-up 


The responsible CMO will prepare a directive or 
letter of instruction from the Apollo Program 
Director or Center Director, as appropriate, to 
implement corrective action for deficiencies 
identified during the audit. The CMO's will 
also take all proper follow-up action (including 
a repeat audit if necessary) to verify that 
directed corrective actions are implemented. 

6. AUDIT CHECKLIST 

The following questions cover a wide range of data to 
illustrate the type of information which may be of 
concern to an audit team. Some of them may be deleted, 
and other questions may be added to satisfy the need 
of each particular audit. 

6 . 1 Organization 


a. Is there a current organization chart? 

b. Where in the organization is the configuration 
management office established? 

c. How ma^y personnel are in CMO? Civil Service? 
Contractor support? 

d. How many personnel are there in the Contractors 
CMO? 

e. Are there organization charts of the CMO? 

f. Are there current writeups of the individual 
job responsibilities? 

g. How do these writeups compare with the actual 
job responsibilities? 

h. Is there a flow chart showing the implementation 
of approved engineering changes? 

i. Is there a flow chart showing the approval of 
engineering changes? 

j. Does Configuration Management have the approval 
of top management? 

k. Are there existing policies and/or procedures 
for implementing configuration management? 

l. Is interface control a part of the Configuration 
Management functions? 
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6 . 2 Training 


a. Is there a configuration management training course? 

b. What personnel take the course? 

c. Have all engineering management personnel taken 
the course? 

d. How often is the course given? 

e. What written material is utilized in giving 
the course? 

6 . 3 Configuration Management Office Functions 


a. Do Configuration Management Plans, Manuals, 
Procedures, Flow Charts, Requirements, Doc- 
uments, etc. exist and are they implemented and 
followed? 

b. Do files contain all specifications? 

c. Are specifications adequate? 

d. Are specifications up-to-date? 

e. Is there a specification tree? 

f. Is there a specification index? 

g. Do the project personnel have instructions on 
how to prepare specifications? 

h. Are standard technical requirements 
(standardization, humidity, packing, etc.) 
enumerated for specifications? 

i. If a deviation occurs, what procedure is followed? 

j. Is there a Part II CEI Specification? 

k. Was the Part II CEI Specification approved 

at FACI? Are material and process specifications 
used? 

l. Do change (ECP) files contain all applicable 
change paper? 

m. Are meaningful agendas and minutes published 
for CCB meetings? 

n. Are changes pre- coordinated with other CCB/ 

CMO when interface is affected? 

o. Are CCBD's accurate, concise and do they 
have proper descriptions of required actions 
when appropriate? 

p. Does an adequate Configuration Identification and 
Accounting Index exist? 

q. Does a change tracking system exist which follows 
a change from initiation to incorporation? 

r. Does the affected Contracts office implement 
CCBD's as directed thereby? 

s. Are Class II changes monitored? 

t. Does Quality Assurance monitor configuration? 

u. Are "process specs" controlled where necessary 
(Approval and changes by CCB action) ? 

v. Are formal ECP ' s submitted for waivers and 
deviations? 

w. Are ECP's adequate, descriptive and timely? 

x. Does the CMO participate in Design Reviews 
and Inspections? To what extent? 

y. Are specifications and all SCN's/ECP's 
approved by CCBD's? 
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z. Are adequate Acceptance Data Packages required 
and maintained at all sites and Centers? 
aa. Are field "make-work" changes fed-back to all 
required areas? Are affected drawings updated 
and subsequent ef fectivities covered by ECP's? 
bb. Are MRB actions monitored to ensure Configuration 
changes do not occur by MRB actions? 
cc. Do like solutions (Part II specs) exist for all 
requirements for subsequent ef fectivities unless 
fchanged by approved ECP after the specification 
is baselined? Does contractor's release system 
stop EO release by closing out internal 
authorizing paper (such as MCR's) unless an ECP 
is approved? 

dd. Is there a drawing manual. Is it followed? 
ee . Is there a procedure which describes the 

release function? Is it effectively followed? 
ff. Does the release system release only approved 
drawings and documents? 

gg. Are revisions to drawings and documents released 
only upon approval by cognizant change authority? 
hh. Do Contracting Office functions implement CCBD's 
completely and in a timely manner? 


6 . 4 Configuration Control Board 


a. 

b. 

c. 

d. 

e . 

f . 
g- 

h. 

i. 
j- 

k. 

l . 

m. 

n. 

o. 
P- 


q* 


Is there a change control system? 

Is it in writing? 

Is the procedure well distributed? 

Is the procedure followed? 

How ma$y CCB's are there? What levels? 

Do all changes go through the CCB? 

Is approval authority limited to the 
chairman of the CCB? 

How is a change presented to the. CCB? 

How does the CCB document their decisions? 

Is there a log of ECP numbers? 

To whom does the chairman of the CCB report? 

Are all affected organizations represented on 
the CCB and do they regularly attend meetings? 

Is approval authority delegated by the CCB 
Chairman? To whom and to what extent? 

Does the CCB meet on a regularly scheduled basis? 

Are CCBD's signed at meetings? 

Does the CCB approve "Product Improvement" 
changes which do not have significant cost or 
performance gains? 

Is there a follow-up system to assure compliance with 
published policies and procedures? 


6. 5 Design Reviews and Inspections 


a. Do plans exist for conduct of PDR, CDR and FACI? 

b. Are reviews scheduled? 

c. Are minutes kept which are descriptive of the 
conduct? 

d. Are specifications baselined (approved) by 
CCBD's at appropriate points? 
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e. Are CCBD's contractually implemented? 

f. Do Part I Requirements and Part II Design 
Definition changes require ECP*s to be sub- 
mitted (formal change control implemented) 
after approval? 

g. At FACI: 

1. Was the Release system checked for adequacy? 

2. Was the part number system checked? 

3. Were all approved ECP's checked for incor- 
poration? 

4. Was manufacturing documentation checked to 
ensure incorporation of latest engineering 
drawing changes? 

5. Did actual hardware configuration agree 
with the released engineering drawings? 

6. Did follow-up occur which closed out open 
Configuration Management action items? 

6 . 6 Hardware/Software Modifications Requiring Retrofit 
by Kit 

a. Is there a tracking system for approved modifi- 
cations? 

b. How are these modifications picked up? 

c. How are these modifications closed out? 

d. When are these modifications closed out? 

e. Can the number of open modifications be 
determined at any time? 

f. Is there a means of determining whether a modifica- 
tion will delay a launch or delivery by late 
completion? 
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CONFIGURATION IDENTIFICATION 
AND ACCOUNTING REPORTS REQUIREMENTS 


1 . PURPOSE 

This exhibit establishes the requirements for generating and 
maintaining the necessary information for preparation of the 
Configuration Identif ication Index Report (CIIR) and the Con- 
figuration Status Accounting Report (CSAR) . These two reports 
may be combined into a single reports Conf iguration Identifi- 
cation and Accounting Index. 

2 . SCOPE 

This exhibit identifies and defines the data elements necessary 
for the generation of these reports. The requirements set 
forth herein are considered the minimum for Apollo config- 
uration management, and may be added to as Center needs require. 
Any format which contains these minimum reporting requirements 
and satisfies the Center's needs will be acceptable. 

3 . REFERENCES 

Exhibit XVII "Explanation of Terms" 

MIL-STD-480 30 October 1968 "Configuration Control - 

Engineering Changes, Deviations 
and Waivers" 

4. RESTRICTIONS 

This exhibit shall not be used by a contractor as authorization 
to acquire Automatic Data Processing System (ADPS) equipment, 
personnel, other equipment or facilities without specific 
authorization from the contracting officer through formal chan- 
nels . 

5 . APPLICABILITY 

This exhibit applies to all Apollo organizations, NASA or con- 
tractor, responsible for the preparation of Configuration Identi- 
fication Indexes and Configuration Status Accounting Reports, and 
to all organizations and contractors providing the data elements 
described herein. Each contractor under contract to the procuring 
agency shall be responsible for the compliance of his subcon- 
tractors, vendors, or suppliers to the extent his subcontractors, 
vendors or suppliers are involved in configuration management 
reporting . 

6 . RESPONSIBILITIES 

The responsibility for publication of reports and/or data sub- 
mittal to the publishing agency shall be as directed by the 
procuring agency. 
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7. CONFIGURATION MANAGEMENT REPORTS 

7 - 1 Configuration Identification Index Report (CIIR) 

The Configuration Identification Index Report is the one 
authoritative document which depicts the approved 
configuration of all contract end items and, as such, 
must contain the following information as a minimum, 

7.1.1 Upon completion of the first article configu- 
ration inspection, but no later than the signing 
of the DD250 (or NASA equivalent) , the following 
baseline information shall be prepared and sub- 
mitted for inclusion in the CIIR. 

a. Contractor 

b. End item nomenclature 

c. Specification number 

d. End item identification number 

e. Baseline part number 

f. Serial number 

7.1.2 After establishing the baseline configuration 
at FACI , all changes shall be processed in 
accordance with MIL-STD-480 as implemented 

by the Centers. Upon approval of ECP ' s by the 
NASA, the following information shall be 
prepared and submitted for inclusion in the 
CIIR. 

a. Contractor 

b. CCBD number 

c. ECP number 

d. ECP title 

e. Effectivity 

f. New part number 

g. Modification instruction number 

h. Estimated man-hours for incorporation 

i. Contractual authority 

7 . 2 Configuration Status Accounting Report (CSAR) 

7.2.1 To insure adequate control and timely modification 
of delivered hardware, and to prepare a document 
which will serve as an authoritative source for 
the actual configuration of all delivered hardware, 
the following information shall be prepared and 
submitted, as available and on a schedule as 
agreed to by the procuring agency, for inclusion 
in the CSAR. 

a. Contractor 

b. ECP number 

c. ECP title 

d. End item identification number 

e. Effectivity 

f. Contractual authority 

g. CCB directive 

h. Modification instruction numbers 
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i» New part number 
j„ Affected end items 

k. Location 

l. Kit identification number 

m. Incorporation date (production) 
n- Scheduled kit delivery date 

o. Actual kit delivery date 
p* Incorporation date (retrofit) 

q. End item serial number (spares/chassis) 

r. Old part number (spares) 

s. New part number (spares) 

t. Kit identification number (spares) 

u. Scheduled kit incorporation date (spares) 

v. Actual kit incorporation date (spares) 

w. Location (spares) 

7 . 3 Definition of Data Elements 

7*3.1 Contractor . The name of the contractor who 
has cognizance over the end item. 

7.3.2 End Item Nomenclature* The official name, 
title or designation of the end item. 

7.3.3 Specification Number. The number of the 
specification to which the end item was built. 

7.3.4 End Item Identification Number. Numeric 
designation or identifying number assigned to 
the end item. 

7.3.5 Baseline Part Number. The initial or original 
part number assigned to the baselined end item. 

(Same as drawing number.) 

7.3.6 Serial Number. All serial numbers assigned to 
the end item. 

7.3.7 ECP Number. The number assigned by the 
contractor to the ECP. 

7.3.8 ECP Title. Short title indicating nature of 
change . 

7.3.9 Ef fectivity . Serial number of those items that will 
be retrofitted and those that will have the change 
incorporated in production. 

7.3.10 New Part Number. The new part number that will be 
assigned to the end item after the incorporation 
of the ECP. 

7.3.11 Modification Instruction Number. The contractor' s 
retrofit number associated with field changes. Not 
required for ECP's that affect production only. 
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7.3.12 

7.3.13 

7.3.14 

7.3.15 

7.3.16 

7.3.17 

7.3.18 

7.3.19 

7.3.20 

7.3.21 

7.3.22 

7.3.23 


Contractual Authority. The number of the 
contractual change notice that authorized 
the contractor to incorporate the change. 

Configuration Control Board Directive. 

All changes after baselining are approved 
by cognizant Configuration Control Boards by 
means of Configuration Control Board 
Directives. In the case of new ICDs or 
changes to ICDs (IRNs) CCB approval will 
occur after panel technical approval prior 
to contractual implementation. 

Affected End Items. The identification numbers 
of all end items affected by an ECP, including 
the end items of another contractor. 

Location. The geographical location where the 
retrofit change will be incorporated in the 
end item. 

Kit Identification Number. Identification 
number of the retrofit kit to be used for 
incorporating the ECP in a particular serial 
number of the end item. Not required for 
production changes. 

Incorporation Date. The scheduled date by which 
the change is expected to have been incorporated 
in the end item and approved by Quality Control. 

Spare/Chassis End Item Serial Number. The serial 
numbers of the spares or chassis effected by the 
ECP. 

Old Part Number (Spares) . The part number of the 
spare/chassis effected by the ECP. 

New Part Number (Spares) . The new part number 
which an existing spare/chassis will become upon 
incorporation of the ECP. 

Kit Identification and Internal Control Number 
(Spares) . The contractor’s identification numbers 
associated with the retrofit kits that will be 
used for retrofit of spares . 

Incorporation Date (Spares) . The scheduled date 
by which the change is expected to have been 
incorporated in the spare and approved by Quality 
Control , and/or the actual date when it was 
incorporated . 

Location (Spares) . Geographical location where the 
retrofit change will be incorporated in the spare. 
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7.4 Source of Data 


A predominant amount of the data required by 
paragraph 7.0 is obtained from the ECP package , 

FACI package , engineering release package, contract 
change notice, etc. However, certain data elements 
should be derived or obtained from a certain source 
or in a particular manner in order to maintain 
effective control. 

7.4,1 Configuration Control Board. When a 

contractor’s ECP effects or requires a 

change in another contractor's end items, it is 

essential that these interface changes not only 

be technically coordinated and approved but 

that the Configuration Identif ication 

and Accounting Index accurately reflects the 

relationship and ties together these changes. 

The single authoritative document that indicates 
coordination and approved the interface changes 
must be referenced in the Index with the 
corresponding ECP's; thus, changes incorporated 
by interfacing contractors can be related back 
to a single approving authority. Two interface 
conditions are discussed below to indicate what 
constitutes the proper data element for the 
Configuration Control Board Directive entry, 

7 .4.1.1 Two Interfacing Contractors Under 
Contract to the Same NASA Center. 

The Program Manager's CCB would assure 
that the required interface coordination 
and agreements have been accomplished. 

In this case, the approval for the inter- 
face change would be contained in the 
CCB Directive . Thus, all ECP's required 
by the contractors to comply with this 
interface change must reference the CCB 
Directive as the interface authority. 

7. 4.1. 2 Two Interfacing Contractors Under Contract 
to Different NASA Centers ; In this case 
the necessary interface coordination and 
agreements would be accomplished by the 
appropriate inter-center Coordination Panels 
with agreements reflected on the inter- 
face documentation by approval signatures. 
Each Program Manager's CCB would implement 
these agreements by issuing CCB Directives. 
In this case the changes are being imple- 
mented to comply with an inter-center Panel 
agreement, thus any subsequent ECP's shall 
reference the authorizing CCBD. 

8 . REPORT FORMATS 

8.1 The format for these reports, shall be as defined and 

directed by the procuring agency and shall contain as a 
minimum the information required by this exhibit. 
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EXPLANATION OF TERMS 


1 . PURPOSE 

This Exhibit provides contractors and Government agencies with 
explanations of the words, terms and phrases which characterize 
the terminology used throughout the Apollo Configuration Manage- 
ment Manual. 

2 . SCOPE 

The terms selected for inclusion in this Exhibit are those which 
are most frequently encountered. While these terms are explained 
in applicable exhibits, they are repeated herein for emphasis and 
the user’s convenience. 

3. APPLICABILITY 

This exhibit is applicable to NASA agencies and contractors, and 
shall be applied in conjunction with other exhibits of the manual 
when made a contractual requirement. 

4. EXPLANATION OF TERMS 

4.1 Acquisition Engineering 

The engineering required for development, procurement, manu- 
facturing, installation and checkout, during the Acquisition 
Phase of systems/equipment. 

4 . 2 Acquisition Phase 

The period starting after the establishment of the Design 
Requirements Baseline (end of the Definition Phase) until 
the acceptance by the user of the last operating unit in a 
certain series, and all required updating changes resulting 
from the testing have been identified, approved, and incor- 
porated, whichever occurs later. 

4.3 Aerospace Ground Equipment (AGE) 

All equipments required on the ground to make a system, com- 
mand and control system, support system, subsystem, or end 
item of equipment operational in its intended environment . 
This includes all equipment required to install, launch, 
arrest, guide, control, direct, inspect, test (other than 
development tests), adjust, calibrate, appraise, gauge, 
measure, assemble, disassemble, handle, transport, safeguard 
store, actuate, service, repair, overhaul, maintain, or oper 
ate the system, subsystem, end item or component. This def- 
inition applies regardless of the method of development, 
funding or procurement. 
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4 * 4 Apollo Program Specification 

This specification is formated to include all system and 
functional area design, development, test and qualification 
requirements including software in a single document. This 
specification is the basic reference for control of the 
technical scope of the total system, 

4.5 Change Proposal (See Exhibit IX) 

The document which proposes system/equipment changes in 
accordance with applicable bulletins, regulations, and other 
directives . 

4 . 6 Change Proposal/Number (See Exhibit X) 

The sequence number assigned to the change proposal in accor- 
dance with the project office instructions, 

4 . 7 Configuration 

The complete technical description required to fabricate, 
test, accept, operate, maintain, and logistically support 
systems and equipment, 

4 . 8 Configuration Accounting 

Act of reporting and documenting changes made to systems/ 
equipment subsequent to the establishment of a baseline 
configuration in order to maintain a configuration status. 

4. 9 Configuration Control 

Systematic evaluation, coordination, and approval or dis- 
approval of proposed changes to any baseline. 

4 . 10 Configuration Control Board (CCB) 

The functional body within the CMO of the Project Office 
or equipment directorate, responsible for configuration 
control. These boards will be chaired by the project 
director or his designated representative. It is not a 
voting board. The Program Director or a CCB chairman act- 
ing on his behalf, is responsible for making all decisions. 

4.11 Configuration Identification 

The technical documentation defining the approved config- 
uration of systems/equipment under design, development, 
test and manufacturing. 


XVII-2 



EXHIBIT XVII 


4 . 12 Configuration Identification Index 

A document prepared initially during the design and devel- 
opment period of system/ equipment development, and continued 
through the acquisition phase. The document is arranged in 
tabular form and has provisions for inclusion of all changes 
which result from contractor or program office action. 

4 . 13 Configuration Identification Numbers 

The relationship of numbers which, individually or in combin- 
ation, permit accurate selection of the configuration required 
to perform a given function. 

These numbers ares 

a. CEI numbers 

b. Part numbers 

c. Change numbers 

d. Manufacturer's code identification numbers 

4 . 14 Configuration Management 

The formal set of procedural concepts by which a uniform sys- 
tem of configuration identification, control, and accounting 
is established and maintained for all NASA systems/equipment 
and components thereof. 

4.15 Configuration Management Office (CMO) 

The organization within the Project Office or equipment direc- 
torate, which is responsible for the formalization, issuance 
and maintenance of the three aspects of configuration manage- 
ment - configuration identification, control, and accounting? 
for the administration of the CCB? for the direction and super- 
vision of the specification program? and for the transfer of 
all configuration documentation as applicable. 

4 . 16 Configuration Status 

The official NASA documented indication of the actual config- 
uration of a serially numbered system or equipment at any given 
time in relation to an approved configuration. 

4.17 Contract End Item (CEI) 


An arbitrary designation for the portions of a system/equip- 
ment identif iaction as a result of a formal functional anal- 
ysis. It is a functional entity physically related and sel- 
ected for the purpose of system development, procurement, 
and logistics. The following criteria shall be used in the 
selection of an end items 
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a. An end item shall be procurable by the government 
to a single specification, 

b. An end item shall be identified by a single top 
drawing which has been prepared in conformance with 
appropriate military specifications, 

c. An end item shall be identified by a separate and 
distinct part number and serial number, 

d. The physical and functional characteristics of an 
end item shall be such that its configuration can 
be controlled and documented economically regard- 
less of the number of changes approved and/or incor- 
porated therein, 

e. The location of the distinct/separate parts of an 
end item should be such that they are not remotely 
located with respect of one part to another , i.e., 
black boxes should be located in the same area AVE 
system compartment, same maintenance area, etc, 

f« By definition, magnetic tapes and card decks used 
with checkout equipment are classified as end items 
and subject to change control. 

4.18 Contract End Item Detail Specification (Facility) (See 
Exhibit III) 

The FCEI specification is composed of two distinct parts, 
each of which has distinct and different uses in FCEI ac- 
quisition, Part I, facility criteria, is a product of a 
Program Definition Phase or requirements analysis, and is 
the engineering instrument used to contract for design and 
development of the FCEI. Part II of the FCEI specification, 
the construction bid package (contract, plans and specifi- 
cation) , is a product of the design and development contract. 
Part II specifies the FCEI in terms of the detailed product 
configuration requirements of the facility suitable for 
contracting actual facility construction. 

4 . 19 Contract End Item Detail Specification (Identification 
Item) (See Exhibit IV) 


A CEI specification is prepared for each end item of equip- 
ment categorized as an identification item. An "identifica- 
tion item" is one which satisfies the following criteria: 

a. It can be qualified by inspection and/or simple 
demonstration , 

b. Quality control at the production level can be the 
basis for verification of quality, and acceptance 
can be based on verification that the item conforms 
to the drawings. 
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c. Because of its use and simplicity of function and 
design, few design changes are anticipated once 
the product configuration baseline for the item is 
established* 

4. 20 Contract End Item Detail Specification (Prime Equipment) 

(See Exhibit II) 

The CEI (prime equipment) specification specifies designs, 
development, test and acceptance requirements for a single 
CEI type-model-series, which cannot be defined be the sim- 
plified formats of an identification specification or a 
requirements specification. The CEI specification is com- 
posed of two distinct parts each of which has distinct and 
different uses in the contractual control of CEI acquisi- 
tion. Part I is a product of a Program Definition Phase 
or requirements analysis, and is the engineering instrument 
used to contract for design and development of the CEI. 

Part II of the CEI specification is a product of the design 
and development contract. Part II specifies the CEI in 
terms of the detail product configuration requirements of 
the item qualified (or to be qualified) under the terms and 
conditions of the design and development contract. 

4.21 Contract End Item Detail Specification (Requirement Items) 

(See Exhibit V) 

A CEI specification is prepared for each end item of equip- 
ment categorized as a requirement item. A "requirement 
item" is one which satisfies the following criteria^ 

a. It has been developed. 

b. It is in NASA inventory. 

c. It is required to support an item or items being devel- 
oped, either to be used with, or to be assembled into, 
that item (s) . 

4.22 Contract End Item Number 

The CEI number is a permanent number assigned by the con- 
tractor to identify a contract end item. 

4.23 Critical Design Review (CDR) 

The critical design review is a formal technical review of 
the design of a contract end item (CEI) . The CDR is accom- 
plished when the detail design is essentially complete in 
order to formally establish the design as the basis for 
supporting activities, e.g., preparation of provisioning 
documentation preparation of technical manuals, actual pro- 
visioning of initial spares, etc. The primary product of 
the CDR is formal identification and NASA approval of speci- 
fic engineering documentation which defines the design of 
the CEI, and which will be released for manufacturing of the 
unit that establishes the product conf iguration baseline 
("first article" , or equivalent). 
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4 o 24 Definition Phase 

The period preceding the Acquisition Phase, during which 
the Apollo Program Specification is completed and Part I 
of the end item specification is completed. 

4 „ 25 Design Requirements Baseline 

The design requirements baseline is established at the 
beginning of the Acquisition Phase and consists of the com- 
posite of design requirements for a single contract end item 
contained in an approved Part I to the detail specification 
for the CEI . Part I of the specification for essentially 
all CEI * s is available at a single point in time, the design 
requirements baseline for all CEI's can be clearly identified 
as a system baseline. 

4*26 Detail Specification (Critical Components) (See Exhibit VI) 

Detail specifications are required for components which have 
been identified in a contract end item detail specification 
as "engineering critical components" and/or "logistic criti- 
cal components " . 

4.27 Direct Support Real Property Installed Equipment (DS-RPIE) 

Individual RPIE items of equipment, systems or subsystems that 
are essential to the launching and guidance of a space vehicle, 
the absence of which would preclude the system* s performing 
its assigned mission. 

4.28 Ef fectivity 

The specific contract end item family and serial number (s) 
to which part numbers, ECP*s, CCN*s, DD 250* s waiver docu- 
ments, etc., are addressed. 

4.29 Engineering Critical Components 

Components of a CEI are designated engineering critical 
when : 

a. Qualification of the component will suffice to 
qualify the entire CEI . 

b. Reliability of the component is critical, i.e«, it 
will jeopardize crew safety, mission success, or 
significantly affect the ability of the CEI to per- 
form its overall functions. 

c„ Technical complexity and/or producibility is suffi- 
ciently critical to warrant an individual specifica- 
tion, and the CEI cannot be adequately qualified 
except by separately qualifying the component. 
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4*30 Engineering Data 

Engineering documents such as specifications, drawings, 
standards, lists, or other information prepared by a design 
activity relating to the design, manufacture, procurement, 
reprocurement, test, or inspection of items and services* 

4.31 Engineering He lease Record 

The official data file which records and interrelates 
engineering data, and changes thereto, which technically 
describe and are to be or have been used to build, operate 
and maintain equipments, facilities and systems. 

4*32 Field Release 

The release of engineering data which changes formally 
accepted equipment which is under the jurisdiction of a 
contractor and is progressing through field testing or an 
activation program* 

4*33 First Article Configuration Inspection (FACI) 

The First Article Configuration Inspection (FACI) is a formal 
technical review which establishes the product configuration 
baseline for the contract end item. The primary product of 
the FACI is formal acceptance, by the procuring agency, of 
Part II of the end item detail specification as an audited 
and approved document. 

4.34 Ground Instrumentation Equipment (GIE) 

That equipment used for acquiring and recording any measure- 
ment parameter concerning performance and environmental data 
of the Space Vehicle Equipment. 

4.35 Interface 

A region common to two or more elements, systems, projects 
or programs, characterized by mutual physical, functional 
and procedural properties. Specifically , an Apollo (Inter- 
Center) interface is restricted to Apollo/Saturn Space Vehi- 
cles and supporting equipment; is controlled by an Apollo 
Inter-Center Coordination Panel and affected Center Level II 
Configuration Control Boards (CCB’s); and affects the concerned 
interfacing Centers and/or their contractors* 

4.36 Interface Control Documents (ICD^) 


ICD * s are either drawings or documentation that record the 
compatible design relationships between two or more inter- 
facing end-item designs. 
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4.37 Interface Revision Notice (IRN) 

An IRN is a standard form used by those organizations respon- 
sible for ICD completion or maintenance to record changes to 
an approved ICD or IRN * 

4.38 logistic Critical Components 

Components of a CEI are designated logistic critical when: 

a. Replacement or repair of the component is complicated 
by short supply or long lead time. 

b. At a spares selection conference, NASA identifies the 
component for multiple source procurement or repro- 
curement . 

4.39 Maintenance Support Equipment (MSE) 

That AGE required to restore a system or end item to opera- 
ting condition. MSE includes equipment to perform such func- 
tions as inspect, adjust, calibrate, handle, transport, remove, 
install, repair, assemble, and disassemble. 

4.40 Modification 

A modification is a change to systems/equipment and spares 
approved after the updating changes are identified, approved, 
and placed on contract. 

4 . 41 Multiple Release 

An engineering release record or act in which superseded and 
superseding information are both retained. Eff activities 
for superseded parts are coded as a reference release (no 
manufacture or procurement) and retained on the record along 
with the ef fectivities for superseding parts, coded as a 
requirements release (manufacture or procurement required) . 

The sum of limited ef fectivities for superseded parts and 
the ef fectivities of the superseding part should equal the 
original complete effectivity. 

4 . 42 NASA Engineering Responsibility 

Accountability for the integrity of design, development, 
and performance of NASA systems/equipment. 

4 . 43 Operating Support Equipment (OSE) 

That Aerospace Ground Equipment (AGE) which is a functional 
part of a system which operates with the Space Vehicle (SVE) 
or end item as an essential operating element thereof. OSE 
also includes identical equipment required in the factory to 
check out the Space Vehicle. 
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4 . 44 Operational Engineering 

The engineering required to evaluate and resolve problems 
revealed by operational flight missions* 

4 * 45 Operational Phase 

The period from acceptance by the user of the first opera- 
ting unit until launch* The operational phase overlaps 
the acquisition phase, 

4*46 Operational Use 

For the purpose of this manual, applying to the items of 
systems/equipment necessary to fulfill mission requirements, 

4*47 Preliminary Design Review (PDR) 

This is a formal, technical review of the basic design ap- 
proach for a contract end item* The PDR is accomplished 
prior to, or very early in, the detail design phase in order 
to establish the system compatibility of the design approach. 
The primary product of a preliminary design review is formal 
identification of specific engineering documentation which 
establishes the physicial and functional interface relation- 
ship of the CEI to other system equipment/facilities, 

4*48 Preliminary Interface Revision Notice (PIRN) 

An IRN is "preliminary" (PIRN) until approved by Inter-Center 
Panel Co-Chairmen and by affected Center Level II CCB's through 
officially issued CCBD’s, It then becomes an official change 
to the parent ICD, 

4.49 Prime Equipment Item 

The more complex contractor designed contract end items that 
require extensive functional tests while in the assembled 
condition* 

4.50 Product Configuration Baseline 

The technical description comprised of the CEI specification 
and applicable engineering drawings, against which the First 
Article Configuration Inspection (FACI) is performed, will, 
upon satisfactory completion of the inspection, constitute 
the product configuration baseline for the CEI series, 

4*51 Production Release 


The engineering release of a production or construction 
drawing for manufacture, construction or procurement of the 
items thereon, and for their incorporation in CEI * s by other 
than service action. 
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4*52 Program Element 

A portion of a system which performs a single major func- 
tion including one or more contract end items, and is norm- 
ally assigned a single contractor for integrated design and 
development, e,g,, propulsion, guidance, facilities, commun- 
ication, etc* 

4 . 53 Real Property Installed Equipment (RPIE) 

Non-expendable equipment which has been purchased and installed 
by the construction contractor through Government Construction 
A PP ro P r i a tions and included in or on real property, 

4.54 Reference Release 

An engineering release record or act in which the item re- 
leased is coded to indicate that no manufacture or procure- 
ment is required* Used for specif ications , interface drawings 
and other items which are part of the engineering documentation 
but which do not require production, and for multiple releases, 

4.55 Released Engineering 

The current and total set of drawings and specifications for 
a product which have been completed, formally recorded, and 
made available for manufacturing and/or procurement, 

4.56 Requirements ECP 

An ECP which proposes changes to the requirements contained 
in specifications prepared in accordance with Exhibit I . 

4.57 Requirements Release 

An engineering release record or act in which the items re- 
leased are coded to indicate that manufacture or procurement 
is required as authorized by contract, 

4.58 Space Vehicle Equipment (SVE) 

That equipment which becomes airborne after a launch and 
includes the launch vehicle, as well as the spacecraft, 

4.59 Synthetic Number or Code 

A number or code assigned to a production assembly, station, 
or status, which is other than a part or assembly defined 
and identified on an engineering drawing. 


XVII-10 



EXHIBIT XVII 


4 e 60 System Requirements Baseline 

This baseline is defined by the Apollo Program Specification, 
The approved performance requirements contained in the Pro- 
gram Specification shall establish the system requirements 
baseline for the Definition Phase, 

4.61 Training Equipment (TRE) 

TRE is defined as the equipment required to train government 
(including astronauts) and/or contractor personnel in order 
that they can perform their functions in accomplishing mis- 
sion objectives. 

4.62 Uniform Specification 

The complete contract end item technical description used 
for production release and conf iguration management. It 
will include the referenced military and contractor specifi- 
cations, documents, engineering drawings, production test 
requirements, and corresponding production tests. These 
specifications will result from technical data created in 
the development program. 

4.63 Uniform Specification Program (See Exhibits I through VII) 

The concept of the Uniform Specification Program (USP) is 
based on the fact that the system/equipment is not procured 
by single identifiable systems, but rather by separate end 
items of contractor peculiar items, and commercial "off the 
shelf" items. It is recognized that an end item specifica- 
tion program must be correlated with system procurement 
programs and methods. Therefore, a basic action of the USP 
is the preparation of contract end item detail specifications 
for each provisional end item of the program. The utiliza- 
tion of the contract end item detail specification thus de- 
rived shall be as follows s 

a. Determination of overall system performance for 
operational use. 

b . Rigid control by the Configuration Control Board 
(CCB) . 

c. Acceptance of end items by NASA. 

d. Complete identification of specifications covering 
all end items required to support the program. 

e. Support reprocurement of identical end items where 
required, or similar end items if exact duplication 
of performance is not critical. 
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PREPARATION OF 

CONTRACT END ITEM DETAIL SPECIFICATION 
(COMPUTER PROGRAM) 


PURPOSE 

This exhibit provides instructions for the preparation of the 
detailed specification for each computer program contract end 
item (CPCEI) and for any necessary addenda thereto. 

SCOPE 

These instructions are applicable to the specification 
for end items categorized as "computer program". The 
instructions contained herein define the content and 
format for each of the two parts of the CPCEI detail 
specification. Also included are instructions for the 
preparation of addenda to the CPCEI specification. 

2 . 1 CPCEI Specification 


The computer program contract end item (CPCEI) 
specification is the detailed specification of 
computer programs which have been designated as 
end items by the procuring agency. The two parts 
to the CPCEI specification are: 

Part I - Performance and Design Requirements : 

This part is used to specify require- 
ments peculiar to the design, development, 
test, and qualification of the CPCEI. 

Part I is usually a product of the 
definition phase and is used to contract 
for the design and development of the CPCEI 

Part II - Computer Program Technical Description : 

The Part II specification is the detailed 
technical description of a CPCEI as 
actually implemented by the contractor. 

The Part II specification is a product 
of a program acquisition phase and is one 
of the instruments used for CPCEI 
acceptance. The Part II specification 
defines the product configuration base- 
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line. It also serves as an instrument for sub- 
sequent use by in service and/or contractor 
personnel in diagnosing trouble, making adap- 
tation changes, and designing modifications to 
the CPCEI . 

2 . 2 Specification Addenda 

An addendum to a CPCEI specification establishes requirements 
for a new end item which, in terms of performance and design, 
is so much like an existing CPCEI that it is desirable to 
refer to an existing specification on an "add" and "delete" 
basis. 

3 . APPLICABILITY 

This exhibit is applicable to NASA agencies and NASA contractors 
responsible for the development of computer programs which are 
classified as end items. Guidelines for the selection of end items 
are given in Exhibit XI. Each contractor to the Government shall 
be responsible for compliance by his subcontractors, vendors, and 
suppliers to the extent that his subcontractors, vendors, and sup- 
pliers participate in the preparation of this type of specification. 

4 . APPLICABLE DOCUMENTS 

DSM 4120. 3-M 1 April 1966 "Standardization Policies, Pro- 

cedures and Instructions" 

Exhibit X "Requirements for Configuration 

Identification Numbers" 

MIL-STD-480 30 October 1968 "Configuration Control - Engineering 

Changes, Deviations and Waivers" 

5. EXPLANATION OF TERMS 
(See Exhibit XVII) 

6 . PROCEDURAL REQUIREMENTS 

These procedures are based on the policies and practices of the 
procuring agency for configuration management. It is recommended 
that contractors review these policies and practices as part of 
implementing the procedural requirements in this exhibit. 

6 . 1 Computer Program Contract End Item Detail Specification 

The CPCEI specification defines requirements for a computer 
program that has been identified as a CPCEI. The CPCEI speci- 
fication is composed of two distinct parts. Each of which has 
distinct and different uses in the contractual control of CPCEI ac- 
quisition. Each of the two parts, when prepared to comply with 
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these instructions, is complete in content and format with 
respect to its intended use. The CPCEI specification 
is controlled and accounted as an entity, using a single 
end item configuration chart, and a single specification 
change log. (See Exhibit VII) 

Part I is a product of a program definition phase or 
requirements analysis and is the technical requirements 
document used to contract for design and development of 
the CPCEI. Contractor compliance with Part I is deter- 
mined by evaluation of qualification and other test 
records. The Part I specification describes in 
mathematical, logical, and operational language all 
of the detail necessary to initiate and carry out the 
design of a required computer program contract end item. 

In addition to providing the primary "design to" guide 
for the computer programming design and development 
effort during the acquisition phase, this document pro- 
vides (a) the basis for approval by the procuring and 
using agencies of the fine detail of the performance of 
the computer programs to be developed, (b) the instrument 
which defines all essential interfaces with other com- 
puter programs, equipment, and communications links, 

(c) the direct basis for the development of support 
documentation associated with operation and use of the 
computer program, and (d) the basic vehicle for con- 
figuration control of the design of the CPCEI throughout 
acquisition and operational phases of the system cycle. 

Part II of the CPCEI specification is a product of the 
acquisition phase. It provides a complete technical 
description of the CPCEI functions, structures, operating 
environment, and constraints, data organization, diagram- 
matic/narrative flows, and source statement/machine 
language listings. Part II must be identical to the 
actual CPCEI which results from the contractor's develop- 
mental work during the acquisition phase, and which is 
qualified (or to be qualified) under the terms and con- 
ditions of the contract as meeting the detailed performance 
requirements initially specified in Part I of the CPCEI 
detail Specification. The integrity of Part II is estab- 
lished by First Article Configuration Inspection (FACI) 
prior to its acceptance by the procuring agency. Accep- 
tance is dependent upon the accuracy and completeness with 
which it describes both the gross and detailed structure 
and functioning of the computer program. 

6 . 2 Addenda to Computer Program Contract End Item Detail 
Specifications 
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Origination of an addendum to a CPCEI detail specifica- 
tion creates a new specification. It is used when an 
item to be designed and developed is so like an existing 
CPCEI that it is desirable to restrict design activity 
to "engineer to the same criteria, with these additions/ 
deletions." An addendum changes a basic CPCEI detail 
specification by adding or deleting requirements on a 
paragraph-by-paragraph basis. Addenda shall be iden- 
tified with a specific issue of a basic specification. 

The specification so created (basic specification plus 
addenda) then becomes controlled and maintained as a 
separate and distinct specification, to be updated and 
revised as necessary, independent of changes to the 
basic specification from which it was created. 

6 . 3 Detailed Instructions for the Preparation of the CPCEI 
Specification 

The contents of the CPCEI Specification shall be arranged 
in accordance with the format and paragraph headings 
given in 6.3.1 (Part I) and 6.3.2 (Part II). General 
deviatations from the requirements of this exhibit require 
prior approval of the procuring agency. Each CPCEI 
detail specification which deviates from the general re- 
quirements of this exhibit shall cite, in Section 10 
"Appendix", the procuring agency instrument authorizing 
the deviation. For convenience in describing the minimum 
essential content, the paragraphs outlined in 6.3.1 and 
6.3.2 are arranged in a format which shall apply if the 
specification is to be issued as a single document. How- 
ever, each part of the specification required for a large 
computer program is typically too complex and bulky 
to be published and distributed physically in one bound 
volume. In this case, each part may be arranged 
into separate volumes corresponding to individual 
functional elements, or as determined by mutual agree- 
ment between the contractor and the procuring agency 
to meet the requirements of a particular system. 

Note: In the descriptions to follow, the term "computer 

program component" (CPC) is used to denote the separately 
produced subprograms which comprise a CPCEI. These sub- 
programs are usually separately compilable, perform a 
specified function or set of functions that are related, 
and are produced by a single programmer. The Part II 
Specification contains a detailed description of each 
CPC in a CPCEI and denotes the relationship between them. 
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6.3.1 CPCEI Part I Specification 

This subparagraph contains a description of 
the paragraph headings of a CPCEI Part I 
Specification. 


"Title Page' 1 - (Computer Program Contract End Item Detail 
Specification) - The title page shall conform to the format 
of Sample Format "A" and include the following information 
referenced to Sample Format "A": 


"Specification Number" 


"Revision Identification" 


"Release Date" 


An identifier unique, within 
the system, to this CPCEI. 

(See Exhibit X.) For 
CPCEI 1 s, the first two (2) 
characters (the prefix code) 
shall be "CG" . 

Sequentially assigned character (s) 
to uniquely identify each re- 
vision of the specification. 

Date formally released by the 
preparing agency. 


Note : The specification number and revision identification may 

be composed of either, or both, alpha and/or numeric char- 
acters. Under no circumstances shall the combination of 
specification number and revision identification exceed 15 
characters. (See Exhibit X.) 


"CEI " 


Contract End Item Number. 
(See Exhibit X.) 


"Approved Nomenclature" 


In accordance with Exhibit X 
and standard practice. 


"System Identification" List the system or systems which 

the CPCEI is designed to support. 
For CPCEIs which cannot be iden- 
tified with specific systems, enter 
the phrase "Not System Computer 
Programs". 


The title page shall be followed by introductory material as 
appropriate, including the End Item Configuration Chart and the 
Specification Change Log. 
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“Introductory Page" - (Part I of CPCEI Specification) - 
The introductory page shall conform to the format of 
Sample Format "B" . The identifying information appear- 
ing on this page shall be identical to the respective 
element of information appearing on the CEI specifi- 
cation title page. The preparing activity and the 
NASA office with computer program responsibility for 
the CPCEI shall validate the basic Part I in the ap- 
proval blocks. A general outline of the following 
paragraphs is given in Sample Format "C". 


Section 1/ "Scope" - This section of the CPCEI specifi- 
cation shall begin with the following opening phrase: 
"This part of this specification establishes the re- 
quirements for performance, design, test, and qualifi- 
cation of a CPCEI identified as (insert nomenclature 
and contract end item number) . This CPCEI is used to 

(provide) (accomplish) This CPCEI requires 

Subsequent sentence-paragraph (s) shall contain 
a summary of the purpose of the specification, a brief 
description of the functions to be performed, and a 
brief summary of the content and composition of the 
specification. 


Section 2, "Applicable Documents" - This section of 
the CPCEI specification shall begin with the following 
lead phrase: "The following documents, of exact issue 
shown, form a part of this specification to the extent 
specified herein. In the event of conflict between 
documents referenced here and the detailed content of 
Sections 3, 4, and 10, the detailed requirements in 
Sections 3, 4, and 10 shall be considered superseding 
requirements." Those documents (specifications, 
standards, drawings, bulletins, manuals, etc.) which 
are applicable to paragraphs within other sections 
of the specifications shall be listed. Within the 
body of the specification, reference to those docu- 
ments shall be by reference to their basic document 
number or other definitive designation. The format 
in listing the applicable documents shall comply with 
the Defense Standardization Manual 4120. 3-M. 


Section 3, "Requirements" - This section shall con- 
tain performance and design requirements for the 
CPCEI. This section shall include the functional 
requirements for the CPCEI and establish those 
requirements which will be used for verifica- 
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til on during test* This section shall define the CPCEI and 
specify design constraints and standards necessary to assure 
compatibility of the CPCEI with other computer programs and 
equipments* Performance and design requirements included 
herein are allocated from, identical with, or in recognition 
of, requirements established by the system specification. 
Requirements included in the system specification, which 
are directly related to requirements specified herein, shall 
be incorporated by reference. Requirements shall be speci- 
fied to the level of detail necessary to establish limits 
for design. Quantitative requirements shall be specified 
within the three principal subparagraphs included herein. 

General and descriptive material may.be included in the 
basic Section 3. 

Paragraph 3.1, “Perf ormance ” - This paragraph shall specify 
the functional requirements of the CPCEI. Quantitative re- 
quirements shall be specified within the principal sub- 
paragraphs included herein. General and descriptive material 
may be included in basic paragraph 3.1. 

Paragraph 3.1.1, 11 System Requirements” - This paragraph shall 
specify the limits and/or capacities of the CPCEI performance. 
Requirements specified herein are the product of analysis, 
as well as those contained in the system specification. These 
characteristics are the performance parameters which must be 
specified to constrain design within requirements established 
by primary mission/use of the CPCEI, e.g., for a space track - 
ing system; this could include track capacity, number and type 
of inputs processed, etc. Requirements included herein shall 
be stated in quantitative terms, with tolerances where appli- 
cable. 

Paragraph 3.1.2, "Operational Requirements 11 - This paragraph 
shall specify, in subparagraphs defined below, the operational 
requirements of the CPCEI. Requirements shall be stated in 
quantitative terms, with tolerances where applicable. General 
and descriptive material may be included in basic paragraph 
3.1.2, which shall incorporate, either directly or by reference, 
a functional block diagram or equivalent representation of the 
CPCEI. The graphic portrayal shall be accomplished to the level 
of detail necessary to illustrate the functional operation of the 
CPCEI, the relationships between these functions, and the 
relationships between the functions and other identified 
system functions. This diagram is not intended to be re- 
strictive on computer program design in any way. 

Requirements for separately identified CPCEI functions shall 
be described in subsequent paragraphs as appropriate. A 
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subparagraph shall be included for each operational function, 
plus special functions such as sequencing control, displays, 
error detection and recovery, input and output control, real- 
time diagnostics, operational data recording, etc. The des- 
criptions of these CPCEI functional requirements shall include 
the relative sequencing, periodicies, options, and other 
important relationships of each as appropriate. 

Paragraph 3.1. 2.1, M Function 1 M - The basic paragraph shall 
begin with descriptive and introductory material which defines 
the function and its relationship to other functions. Then, 
the following three subparagraphs shall specify the quantita- 
tive requirements concerning the function. 

Paragraph 3.1. 2 .Id, "Source and Type of Inputs” - This para- 
graph shall specify the source (s) and type(s) of input informa- 
tion associated with this function of the CPCEI. This shall 
include a description of the information, its source (s) and, in 
quantitative terms, units of measure, limits and/or ranges of 
units of measures, accuracy /precision requirements, frequency 
of arrival information, etc., where applicable. 

Paragraph 3. 1.2. 1.2, "Destination and Types of Outputs” - This 
paragraph shall specify the destination (s) and type(s) of 
output information associated with this function of the CPCEI 
as a result of the processing described in paragraph 3. 1.2. 1.3. 
This shall include a description of the information, its desti- 
nation (s) and, in quantitative terms, units of measure, 
accuracy/precision requirements, frequency of output information, 
etc., where applicable. 

Paragraph 3. 1.2, 1.3, "Information Processing” - This para- 
graph shall specify the information processing associated 
with this function. The paragraph shall incorporate a detailed 
prose and mathematical description, including necessary logical 
concepts, timing requirements, mathematical techniques, re- 
quired accuracies with tolerances, data manipulation considera- 
tions, and options, A graphic portrayal of this function shall 
be included for clarity as appropriate. 

Paragraph 3.1.2,n, function n M - 

Paragraph 3.1.2.n.l, ''Source and Type of Inputs" - 
Paragraph 3.1.2.n.2, "Destination and Types of Outputs” - 
Paragraph 3.1.2.n.3, n Information Processing" - 
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Paragraph 3.1.3, "Data Base Requirements” - This paragraph 
shall specify, in descriptive and quantitative terms, the 
requirements for all parameters which affect the design of the 
CPCEI. The detailed definition of parameters shall include 
a description of the data and quantitative definitions of units 
of measure, ranges of units of measure, and accuracy /precision 
requirements where applicable. In addition, wherever applicable, 
this paragraph shall specify the methods necessary to convert 
these parameters into a form suitable for use by the computer 
program. In the case of a multi-site system in which the 
actual data values of certain parameters will vary among site 
installations, the complete set of such site adaptation para- 
meters shall be identified either directly in a separate sub- 
paragraph or by reference. 

Paragraph 3.1.4, “Human Performance '* - Human performance/ 
human engineering requirements for the CPCEI shall be specified 
in this paragraph; for example, minimum times for human decision 
making, maximum time for program responses, maximum display 
densities of information, clarity requirements for displays, 
etc. For CPCEIs which directly support a system (s) , this 
paragraph shall cite the appropriate paragraph (s) of the 
system specification which establish the human performance/ 
human engineering requirements for all system equipment, and 
incorporate requirements peculiar to this CPCEI on an add 
and/or delete basis. 

Paragraph 3.2, "CPCEI Definition" - This paragraph shall, in 
subparagraphs included herein, specify the functional rela- 
tionship of the CPCEI to other equipment/computer programs 
and identify government furnished computer programs incor- 
porated in the CPCEI. General and/or descriptive material 
may be included in basic paragraph 3,2. 

Paragraph 3.2.1, "Interface Requirements” - This paragraph 
shall specify, either directly or by reference, requirements 
imposed on the design of the CPCEI because of its relation- 
ship to other equipment/computer programs. It shall also include 
detailed interface definitions resulting from contractor 
analysis and requirements contained in the system specifica- 
tion. General and/or descriptive material may be included in 
basic paragraph 3.2.1. Quantitative requirements shall be 
included in the subparagraphs included herein. 

Note: Interfaces defined in this section shall include, at 

a minimum, all relevant characteristics of the computer, such 
as memory size, word size, access and operation times, interrupt 
capabilities, and special hardware capabilities. If the 
compiler/as sembler is another, or part of another, CEI , the 
computer program language (s) to be employed shall be specified 
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as one of the interfaces in subparagraph 3. 2.1. 2. If the 
compiler/assembler is a Government-furnished component to be 
incorporated into this CPCEI, it shall be referenced in sub- 
paragraph 3,2.2* If the compiler/assembler is to be constructed 
as part of the development of this CPCEI, the language character- 
istics are to be defined under paragraph 3.1, "Operational Re- 
quirements", 

Paragraph 3.2.1. 1, "Interface Block Diagram" - The relation- 
ship of the CPCEI to other equipment/ computer programs with 
which it must interface shall be graphically portrayed in 
this paragraph. This paragraph shall incorporate, in sub- 
paragraphs as appropriate, either directly or by reference, 
a functional block diagram or equivalent representation of 
the interface requirements of the CPCEI. The graphic por- 
trayal of the CPCEI shall be accomplished to the level of 
detail necessary to identify the functional interfaces be- 
tween the CPCEI and other identified equipment/ computer 
programs . 

Paragraph 3. 2.1,2, "Detailed Interface Definition" - This 
paragraph shall specify, in subparagraphs as appropriate, 
the functional relationship of the CPCEI to interfacing 
equipment and computer programs. This information shall be 
given in quantitative terms, with tolerances where applicable, 
to the level of detail necessary to permit design of the CPCEI, 
Functional interfaces shall specify the input/output require- 
ments of the CPCEI in terms of data rate, message format, etc. 

In addition, this paragraph shall specify design requirements 
imposed upon other equipment /computer programs as a result 
of the design of this CPCEI, e.g., card formats, operator 
console equipment, display formats, etc. This paragraph 
shall incorporate, either directly or by reference, interface 
drawings and/or other documentation necessary to specify the 
functional interfaces of this CPCEI with other equipment/ 
computer programs. 

Paragraph 3.2.2, "Government-Furnished Property List" - This 
paragraph shall list the government-furnished computer programs 
which the CPCEI must be designed to incorporate. The listing 
shall identify the programs by nomenclature, specification 
number, model number if appropriate, and associated documenta- 
tion. 

Paragraph 3.3, "Design Requirements" - This paragraph shall 
specify, in appropriate subparagraphs, requirements which 
affect the design of the CPCEI and are distinguishable from 
the performance requirements of paragraph 3.1. These re- 
quirements result from general considerations of CPCEI use- 
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ability . These may include but are not limited to require- 
ments for: 

a. The use of programming standards to assure com- 
patibility among computer program components (CPC- 
subprograms or groups of functionally related sub- 
programs) » 

b. Program organization, such as overall program 
segmentation • 

c. Program design resulting from consideration of 
modifications to the CPCEI during operation; for 
example, on-site modification requirements and 
the permissible amount of operational degradation 
allowed during installation of modifications may 
be specified. 

d. Special features, to facilitate the testing of 
the CPCEI. For example, special procedures for 
the design of computer program component inter- 
faces, requirements for intermediate printouts, 
and commentary on the program listing may be re- 
quired. 

e. Expandability, to facilitate the growth of the CPCEI. 

Section 4, “Quality Assurance Provisions'* - Requirements for 
formal verification of the performance of the CPCEI in accord- 
ance with the requirements of Section 3 of this specification 
shall be specified in this paragraph. Formal verification of 
performance of the CPCEI shall determine acceptance of the 
CPCEI. This paragraph shall specify formal verification re- 
quirements to a level of detail which: 

a. Designates verification requirements and methods 
in Section 4 for performance and design require- 
ments in Section 3. The methods of verification 
to be specified herein may include inspection of 
the CPCEI, review of analytical data, demonstration 
tests, and review of test data. 

b. Specifies requirements for verification to the level 
of detail necessary to clearly establish the scope 
and accuracy of the test method. 

c. Permits ready identification of each verification 
requirement specified in Section 4 with the appro- 
priate performance /design requirement paragraph in 
Section 3. 

d. Allocates verification requirements to the sub- 
paragraphs included herein. 
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Note : This section shall not incorporate , either directly or by 

reference, detailed test planning documentation and operating 
instructions* Requirements specified herein shall be the basis 
for preparation and validation of such documents. All test/ 
verification requirements shall be specified within the sub- 
paragraphs included herein. 

Paragraph 4,1, "Implementation Test Requirements 11 - The term 
"Implementation Test" is defined to include all tests of the 
CPCEI other than that accomplished during the integration 
tests (see paragraph 4.2). The implementation test require- 
ments shall be specified in the following subparagraphs. 

Subparagraph 4.1.1, "Design and Development Testing" - This 
subparagraph shall specify the requirements for computer 
program component and program tests conducted in the acquisi- 
tion phase prior to the preliminary qualification tests. 

These are tests performed on the individual computer program 
components and groups of components to establish that the 
CPCEI is ready for preliminary qualification testing. 

These requirements shall be specified in sufficient detail 
to permit design of such tests and to serve as a guide to 
the programmers in computer program component debugging. 

Note: Verification requirements included in a higher level 

specification (e,g., system specification) may be incorporated 
by reference to avoid duplication. 

Subparagraph 4.1.2, "Preliminary Qualification Testing" - 
This subparagraph shall identify the requirements for pre- 
liminary qualification testing. These tests shall verify each 
requirement of Section 3, which can be tested in a simulated 
environment. They are typically held at the contractor's 
development facility and may serve as the basis for transfer 
of the CPCEI to the user's facility. 

This subparagraph shall specify only those preliminary 
qualification requirements which require formal recognition 
by the procuring agency. It shall specify, to whatever 
extent is possible, the location and relative scheduling of 
the tests, the computer-based system components which will 
not be available (and hence must be simulated or ignored) , 
the objectives of the tests, and the program functions to be 
tested. 

Subparagraph 4.1.3, "Special Test Requirements" - In this 
subparagraph all special verification test requirements, if 
any, not included in the above two subparagraphs shall be 
specified. 
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Paragraph 4,2, 11 Integration Test Requirements 11 - This para- 
graph shall identify requirements specified in Section 3 
which cannot be verified until the CPCEI is assembled into or 
used with the computer-based system environment and other 
CPCEI 1 s » Final verification that all requirements in Section 3 
have been satisfied shall be considered here. 

Integration test requirements shall be specified in the 
following subparagraphs. 

Subparagraph 4,2,1, '"General" - This subparagraph shall 
specifiy CPCEI tests which are required in direct support of 
system integration, i.e., integration of the CPCEI, hardware, 
external environment (communication lines, etc.) and operating 
personnel into an operative computer-based system. Considera- 
tion should be given to the impact of training on CPCEI test 
design. Such tests, prior to formal acceptance tests, usually 
involve attempting to run parts of the CPCEI functions on a 
limited basis as components of the computer-based system are 
installed sequentially. This subparagraph shall identify 
each performance/design requirement to be verified in each 
test. 

Subparagraph 4,2,2, "Acceptance/Qualification Test 11 - This 
subparagraph shall specifiy requirements for formal qualifi- 
cation of the integrated CPCEI to demonstrate and/or verify 
that the requirements established in Section 3 have been 
satisfied. This paragraph shall, in subparagraphs as appro- 
priate, specify the requirement and method of verification 
for the requirements specified in Section 3. 

Verification of the requirements may be accomplished by 
inspection, or review of analytical data, or by demonstration, 
or test and review of test data, or combinations of these. 

Section 5, "Preparation for Delivery 11 - This section is not 
applicable to Part I of the CPCEI specification. Requirements 
for preparation of the CPCEI for shipment and delivery are con- 
tained in Section 5, Part II of this specification. 

Section 6, "Notes" - This section shall include information 
which is stated here for administrative convenience only and 
is not a part of the specification for the CPCEI in the con- 
tractual sense, i.e., it shall not include requirements which 
constrain design, development, and qualification of the CPCEI 
and require compliance by the contractor. 

This section of the specification shall include information 
of particular importance to the procuring agency in using 
this particular specification as a contractual instrument for 
acquisition of the CPCEI, either initially or for follow-on 
procurement * 
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Background information or rationale which will be of assistance 
in understanding the specification itself or using the CPCEI 
it specifies may be included herein, e,g. , technical data 
ordering instructions . 

Section 10, "Appendix" - Requirements specified in the appendix 
are contractually a part of the specification, and to the 
extent they impose requirements on design, development, and 
qualification of the CPCEI, they must be satisfied. This 
section may include, but not be limited to, requirements which 
are : 

a. Bound separately for convenience, as in the case of 
a classified appendix or a large body of statistical 
data, 

b. Of a temporary nature, as in the case of an interim 
performance requirement peculiar to early test models 
of the CPCEI. Requirements peculiar to early test 
articles of the CPCEI shall be specified in an 
appendix which adds to, deletes, changes, or estab- 
lished new requirements applicable to Section 3 or 4 
of Part I. 

Instrumentation requirements for test articles of the CPCEI 
shall be specified only to the level of detail necessary to 
establish the type and total capacity of the instrumentation. 
Requirements specified herein (with the exception of instru- 
mentation) shall be specified to the level of detail required 
by the paragraphs in Sections 3 and 4 of Part I to which they relate. 

If any terms, symbols, and abbreviations are used in the body 
of this specification whose meanings are not widely known, 
they may be defined in a Glossary in this section. 
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SAMPLE FORMAT "A" 


Specification No, 

Revision No. 

Release Date 


CONTRACT END ITEM DETAIL SPECIFICATION 
(COMPUTER PROGRAM) 


PERFORMANCE/DESIGN 

AND 

PRODUCT CONFIGURATION 
REQUIREMENTS 


(CEI Number) 

(APPROVED NOMENCLATURE) 

FOR 

(PROJECT OR SYSTEM NAME) (PROJECT OR SYSTEM) 


Approved by 

(Preparing Activity) 


Date 

Contract Number 


Approved by 

(NASA Office) 
Approval Date 
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SAMPLE FORMAT "B" 


Specification No, 

Revision No. 

Release Date 


CONTRACT END ITEM DETAIL SPECIFICATION 
(COMPUTER PROGRAM) 

PART I 

PERFORMANCE/DESIGN 

REQUIREMENTS 

(CEI Number) 

(APPROVED NOMENCLATURE) 

FOR 

(PROJECT OR SYSTEM NAME) (PROJECT OR SYSTEM) 


Approved by 
Date 


(Preparing Activity) 


Contract Number 


Approved by 

(NASA Office)* 
Approval Date 
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SAMPLE FORMAT "C” 

GENERAL OUTLINE OF CPCEI SPECIFICATION PART I 


TITLE PAGE (Overall CPCEI Specification) 
INTRODUCTORY PAGE (Part I) 

1. SCOBE 

2 . APPLICABLE DOCUMENTS 

3. REQUIREMENTS 


3 . 1 Performance 

3.1.1 System Requirements 

3.1.2 Operational Requirements 

3. 1.2.1 Function 1 

3. 1.2. 1.1 Source and Type of Inputs 

3.1.2. 1.2 Destination and Types of Outputs 

3. 1.2. 1.3 Information Processing 

3. 1.2. 2 Function 2 


3.1.2.n Function n 

3.1.3 Data Base Requirements 

3.1.4 Human Performance 

3.2 CPCEI Definition 

3.2.1 Interface Requirements 

3. 2. 1.1 Interface Block Diagram 

3. 2. 1.2 Detailed Interface Definition 

3.2.2 Government-Furnished Property List 

3.3 Design Requirements 
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4 . QUALITY ASSURANCE PROVISIONS 

4*1 Implementation Test Requirements 

4.1.1 Design and Development Testing 

4.1.2 Preliminary Qualification Test 

4.1.3 Special Test Requirements 
4.2 Integration Test Requirements 

4.2.1 General 

4.2.2 Acceptance/Qualification Test 

6 . NOTES 
10. APPENDIX 
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6.3.2 CPCEI Part II Specification 

This subparagraph describes the paragraph headings 
of a CPCEI Part II Specification, 

The overall outline of the CPCEI Specification Part II is con- 
tained in Sample Format "D" with all major paragraphs and sub- 
paragraph headings listed. 

Throughout the Part II Specification, the phrase "Computer Program 
Component" is used to refer to subprograms (separately compilable 
groups of computer program instructions and data) or groups 
("packages") of functionally related subprograms. 

A discussion of the contents of these major paragraphs and sub- 
paragraphs follows . 

"Introductory Page" - (Part II of CPCEI Specification) - The 
introductory page shall conform to the format of Sample For- 
mat "E". The identification appearing on this page shall be 
identical to the respective elements of information appearing 
on the CPCEI specification title page. The procuring agency 
shall validate the basic Part II m the approval blocks. 

Section 1, "Scope" - This section shall contain the follow- 
xng lead phrase: "This specification establishes the require- 

ments for complete identification and acceptance of (insert 
contract end item number and nomenclature) to be formally 
accepted by the procuring agency, subsequent to establishemnt 
of the product configuration baseline. The product configuration 
baseline shall be established by First Article Configuration 
Inspection (FACI) for serial number (insert CPCEI serial 
number) . 

Section 2, "Applicable Documents" 

This section of the specification shall begin with the following 
lead phrase: "The following documents, of exact issue 
shown, form a part of this specification to the extent 
specified herein. In the event of conflict between 
documents referenced here and the detail content of 
Sections 3, 4, 5, and 10, the detail contents of Sections 
3, 4, 5, and 10 shall be considered a superseding require- 
ment." List those documents (specifications, standards, 
bulletins, manuals, etc.) which are applicable to paragraphs 
within other sections of the specification. Within the body 
of the specification, reference to these documents shall be 
by reference to their basic document number or other defin- 
itive designation. 
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Section 3, "Requirements ” 

This section shall specify the detailed configuration of the 
CPCEI , This section shall contain a complete technical 
description of the CPCEI structure and functions, the data 
base, and the individual CPC 1 s . General and/or descriptive 
material may be included in basic Section 3 lead paragraph. 

Paragraph 3.1, "CPCEI Characteristics” 

This paragraph shall contain a description of the overall 
structure and functions of the CPCEI. This description shall 
include: the allocation of functions to the CPC's that com- 

prise the CPCEI; flow charts; timing and sequencing character- 
istics of the CPCEI; and a graphic portrayal of storage 
allocation. This description shall be given in the following 
paragraphs . 

Paragraph 3.1.1, "Functional Allocation" 

The relationship of each computer program component (CPC) to 
the performance and design requirements of the Part I Detail 
Specification shall be specified in this paragraph. This 
relationship will be specified to the level of detail necessary 
to identify how the computer program components are associated 
with the requirements of the functions specified in the Part I 
specification. If the CPC's are grouped into functional entities 
("packages") for separate stages of development and checkout, 
this grouping shall be delineated. 

Paragraph 3.1.2, "CPCEI Flow Chart” 

This paragraph shall graphically portray the operations per- 
formed by the CPCEI. This shall be done by a (series of) flow 
chart (s)' which depict (s) the processing being performed, the 
sequence of operations and the decision points. A "top-level" flow 
chart shall be used to depict in a single figure the overall 
information flow of the CPCEI. This diagram shall reference 
lower level flow charts included in this paragraph, as 
appropriate, to provide more detailed information. The lowest 
level flow charts shall be those which identify as functional 
entities the computer program components described in Section 
3 below. All symbols used in the flow chart shall be defined 
either directly in this paragraph, or on the individual flow 
chart sheets, or by reference to a documented set of standards. 

Paragraph 3.1.3, "CPCEI Timing and Sequencing ” 

This paragraph shall describe the timing and sequencing of oper- 
ations of the computer program components relative to each other. 

If the sequencing is dynamically controlled during the CPCEI 's 
operations, this description shall include the method 
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for sequence control and the logic and input conditions of 
that method. Such factors as timing variations, plus such 
internal operations .as data transfers in and out of core, disc, 
drum, or tape memory, sensing of discrete input signals, and 
the timing relationships between interrupt operations within 
the CPCEI , shall be included. 

Paragraph 3.1.4, 11 Storage Allocation 11 

The relationship of the CPCEI storage requirements to the total 
computer equipment storage capability shall be graphically 
portrayed in this paragraph. This paragraph shall incorporate, 
in subparagraphs as appropriate, either directly or by reference, 
a schematic diagram, or equivalent representation. This 
graphic portrayal of the CPCEI shall be accomplished to the level 
of detail necessary to identify such requirements as: Data base 

allocation, computer program allocation, computer temporary 
memory allocation, and spare storage allocation. If alloca- 
tions cannot be specified precisely or portrayed graphically in 
a manner meaningful for program design, the algorithms used to 
allocate storage will be described. 

Paragraph 3.1.5, n Data Base Characteristics 11 

This paragraph shall include a detailed definition of the content 
and storage location of each file, table, and item within each 
table that is incorporated in the CPCEI data base, as well as 
the storage location of each computer program component con- 
tained in the CPCEI. This paragraph shall contain the following: 

1. "File Description". A list of files that have been 
incorporated in the computer program data base shall 
be included. This shall include a descriptive title 
for each file, length of file, and format, etc. 

2. "Table Description". A list of tables that have been 
incorporated in the computer program data base shall 
be included. This shall include a descriptive title 
for each table, method of indexing the table, length 

of table, and block format for items and itemless tables, 
etc. 

3 

"Item Description". A list of all items contained m 
the computer program data base shall be included. 

This shall include for each item, a descriptive title, 
most significant bit, number of bits, coding type, 
scaling factor, and, if appropriate, units and item 
value, etc. 

4. "Graphic Table Description". The relationship of the 
items specified in 3 above "Item Description" to the 
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tables listed in 2 above and the relationship of tables 
specified in 2 above to the files listed in 1 above will 
be graphically portrayed. This shall incorporate, 
in subparagraphs as appropriate, either directly or 
by reference, a diagram or equivalent representation. 

The graphic portrayal of each table shall be accomplished 
to the level of detail necessary to identify words per 
block, untagged items, bits/items, bit allocation, 
number of blocks and type of table construction. 

5. "Data Organization". A definition of the relationship 
of the items, tables, and files contained within the 
data base and the computer program components described 
in Paragraph 3.2, to locations in computer storage, 
shall be included. This paragraph shall incorporate 
such information as the following: 

a. A list of files, specifying for each file 
the address in storage and number of tables 
contained in the file, etc. 

b. A list of tables, specifying for each table 
the location within the file and number of 
words contained in the table, etc. 

c. A list of items, identifying item location 
within the table, number of bits, item type, 
scaling, etc. 

d. A list of computer program components, 
specifying for each the storage address and 
number of words allocated. 

6. "CPCEI Constants". A list of all constants (e.g., fixed 
values assigned to the parameters defined in 

the Part I CPCEI specification) contained in 
the CPCEI, other than those which are defined as "Adapta- 
tion Data" below, shall be included. The list contained 
herein shall include, as a minimum, a description of each 
constant and its actual numerical or coded value. 

7. "Adaptation DATA". For multi-site computer based 
systems, the actual data required to adapt the CPCEI 
to the environment associated with each site shall be 
listed. For convenience, this information may be 
contained in Section 10, "Appendix". 

8. "Relationship of Computer Program Components to Data 
Base". The relationship of the various computer program 
components to the various tables and items contained 

in the CPCEI data base shall be graphically portrayed. 
This paragraph shall incorporate, in subparagraphs as 
appropriate, either directly or by reference, a 
diagram or equivalent representation. This graphic 
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portrayal of the relationship of CPC's to the data base 
shall be accomplished to the level of detail necessary 
to identify the tables and items within the tables 
required by each computer program component to the 
relationship of the CPC to each table/item (e.g., sets the 
item, uses the item, etc,) , The use of such tables 
and items by each CPC shall be fully described in the 
appropriate subparagraph under paragraph 3*2. 

Paragraph 3.2, "Computer Program Component Characteristics" 

The individualT computer program components ( CPC ' s) shall be 
described in separate paragraphs as required. This description 
shall be given at a level of detail that will define the design 
and configuration of the CPC sufficiently to allow for CPC 
modification and adaption in the operation phase. Each CPC 
shall be described in words, flow charts, and with a listing of 
the instructions used. The basic paragraph 3.2 shall contain 
the following lead phrase: "This paragraph contains the detailed 

technical descriptions of the computer program components 
identified in Paragraph 3;1 of this specification. The 
instruction listings contained herein by inclusion or reference 
specify the exact configuration of the (name of CPCEI) . . 

The following paragraphs will be repeated for each CPC. 

Note : The contents of paragraphs 3. 2, 1-3, 2. n to follow 

represent information that corresponds in general to "program- 
ming specifications" normally produced by analysts, and "coding 
specifications" normally produced by programmers, during the 
acquisition phase. The format described below is intended to 
allow for use of such technical documentation directly as 
portions of the Part II CPCEI specification, thus eliminating the 
need for redocumentation. Other formats may be allowed at the 
discretion of the procuring agency if they meet this intent. 

Paragraph 3.2.1, "Computer Program Component #1 " 

The basic paragraph shall identify the CPC by including as a 
minimum the title, tag (symbolic code) , and component identifica- 
tion number. It shall also include a brief abstract of the 
functions of the CPC, the language (s) in which it is written, and 
its major functional interfaces. The CPC shall then be described 
in detail in subparagraphs as follows: 

Subparagraph 3. 2. 1.1, "CPC No. 1 Description" 

This paragraph shall describe in words, figures, equations, 
and references to the flow chart (s) of Subparagraph 3.2. 1.2, 
the functions and design of the CPC. 

This subparagraph shall contain, as appropriate, a description of: 
the program logic and data flow; equations to be solved; 
algorithms used to solve these equations; timing and accuracy 
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characteristics; and any special conditions for operation 
of the CPC * The description shall be sufficiently detailed to 
facilitate understanding of, and modification to, the listing 
given in subparagraph 3.2.1. Equation derivations and 
numerical analysis shall not be included herein, but may be 
included in Section 6, "Notes". 

Subparagraph 3. 2. 1.2, "CPC No.l Flow Chart" 

This subparagraph shall graphically portray the operations 
performed by the CPC. This shall be done by a (series of) flow 
chart (s) which depict the processing described in subparagraph 
3.2.1. 1, including the sequence of operations and decision 
points, in the CPC. The "highest level" flow chart shall 
depict on a single sheet the overall information flow of the 
CPC and shall reference the flow chart (s) in paragraph 3.1.2 
that identifies the CPC. In general, the lowest level flow 
chart identifies all decision points in the CPC and references 
higher level charts as appropriate. All flow charts shall 
use descriptive symbols and shall reference the program listing 
of the CPC by use of statement labels or tags. All symbols 
used in the flow chart shall be defined in this subparagraph, or 
by reference to paragraph 3.1.2 above, or by reference to a 
documented set of standards, or on the individual flow chart sheets. 

Subparagraph 3 » 2 . 1 . 3 , " Interf aces 11 

This subparagraph shall describe the relationship of the CPC to 
other CPC's to that part of the data base external to the 
CPC, and, to other CPCEI's where applicable. Appropriate 
subparagraphs shall include : 

(a) The exact format, content and source of all input data. 

(b) The exact format, content and destination of all output 

data. 

(c) A list of the subroutines called by the CPC. 

(d) A list of other CPC's which call the CPC. 

(e) A list of external (to the CPC) tables, buffers, con- 
stants, and control registers used by the CPC. 

Subparagraph 3. 2. 1.4, "CPC Data Organization" 

This paragraph shall contain, or refer to a portion of 
subparagraph 3. 2. 1.6 if appropriate, a list and description 
of all data items and tables which are unique to and included 
within the CPC, and shall describe the areas of memory available 
for temporary storage. This list shall include all internally 
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defined symbols and their equivalence and meaning. 

Subparagraph 3.2.1. 5, "Limitations 11 

This subparagraph shall summarize any known or anticipated 
limitations of the CPC „ A listing of all restrictions and con- 
straints which apply to the CPC shall be provided, including timing 
requirements, limitations of algorithms and formulas used, 
limits of input and output data, associated error correction 
sensing, and the error checks programmed into the routines. 

Subparagraph 3. 2. 1.6, "Listing" 

This subparagraph shall contain a complete listing of instruc- 
tions contained in the computer program component ( s) . The 
type of listing provided in this paragraph shall be established 
between the contractor and the procuring agency. The listing 
will show the relationship to the flow diagrams above by appro- 
priate use of statement labels or tags. For convenience, the 
listing may be included in Section 10, "Appendix". 

Paragraph 3.2.2, "Computer Program Component #2" 


Paragraph 3.2.S., "Computer Program Component #— " 


Section 4, "Quality Assurance" 


This section shall specify the tests which must be accomplished 
to demonstrate that the CPCEI performance and configuration is 
as specified in Section 3 of Part II of this specification. 

Paragraph 4.1, "Test Specifications Cross Reference Index" 

In this paragraph, all Test Plan and Test Specification documents 
shall be referenced, with cross indexing to the CPCEI functions 
being tested and the CPCEI components and other computer programs 
required for the tests. This paragraph shall also describe or 
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reference special simulation capabilities required for test/ 
verification of the CPCEI. 

Paragraph 4.2, "Other Quality Assurance Provisions" 

This paragraph shall reference applicable standards and/or 
specify the test/verification requirements, methods and procedures 
which apply to duplication of the computer program (e.g., tapes 
and/or card decks) which are covered by the specification. 

Section 5, “Preparation for Delivery ” 

This section shall specify, in subparagraphs as appropriate, the 
requirements for packaging, marking and otherwise preparing the 
CPCEI for shipment. Where approved existing Government Speci- 
fications are adequate to satisfy current requirements for the 
item and components thereof, these shall be incorporated by 
reference in lieu of providing duplicate detailed requirements 
in this section. Where suitable specifications do not exist, 
requirements peculiar to the CPCEI shall be specified in appropriate 
subparagraphs included herein. 

Paragraph 5.1, “Delivery Procedures" 

This paragraph shall describe the delivery procedures of the 
completed CPCEI. Delivery procedures include a description of 
the product packaging (card decks, tapes, manuals) involved, 
where they shall be stored or delivered to, and the contractors 
responsibilities for, during, and after delivery. 

Paragraph 5.2, "Markings " 

This section shall contain subparagraphs specifying in detail the 
identification markings to appear on every separable portion of 
the CPCEI to be delivered by the contractor and formally accepted 
by the procuring agency. 

Section 6, ,l Notes" 


This section of the specification is not contractually binding. 

It shall include information of particular importance to the 
procuring agency in using Part II of this specification as a 
contractual instrument, or administrative or background infor- 
mation, e.g. , ordering instructions for technical ' data pertaining 
to the computer program, or specific information related to the 
use of the program in future assembly and integration testing. 

It shall not include requirements which constrain design, develop- 
ment, or qualification of the CPCEI. It shall reference the 
technical manuals which can be singularly and peculiarly identified 
with the CPCEI, and which are necessary to its operation and 
maintenance . 
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For each CPC this paragraph shall include any pertinent information 
not included in the above subparagraphs, such as rejected 
alternative CPC designs, the rationale behind the design, reference 
material in support of the algorithms used, and suggestions for 
future modifications to the CPC if changes in requirements should 
materialize. It shall also describe as appropriate the pertinent 
tests which were performed to verify the final implementation of 
the CPC, with key test results included or referenced. 

Section 10, "Appendix” 

This section of the specification may contain requirements which 
are part of Section 3 and/or of Section 4, but are bound separately 
for convenience. Examples are computer-produced listings, multi- 
site adaptation requirements, etc. 
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SAMPLE FORMAT "P" 

GENERAL OUTLINE OF CPCEI SPECIFICATION PART II 

INTRODUCTORY PAGE (PART II) 

1. SCOPE 

2 , APPLICABLE DOCUMENTS 
REQUIREMENTS 

3.1 CPCEI Characteristics 

3.1.1 Functional Allocation 

3.1.2 CPCEI Flow Chart 

3.1.3 CPCEI Timing and Sequencing 

3.1.4 Storage Allocation 

3.1.5 Data Base Characteristics 

3.2 Computer Program Component Characteristics 

3.2.1 Computer Program Component #1 

3. 2. 1.1 Description 

3.2. 1.2 Flow Charts 

3.2. 1.3 Interfaces 

3.2. 1.4 CPC Data Organization 

3 . 2 . 1 . 5 Limitations 

3. 2.1. 6 Listings 

3.2.2 Computer Program Component #2 

3.2.n Computer Program Cpmponent # n 

4 . QUALITY ASSURANCE 

4.1 Test Specifications Cross Reference Index 

4.2 Other Quality Assurance Provisions 

5. PREPARATION FOR DELIVERY 

5.1 Delivery Procedures 

5.2 Markings 

6 . NOTES 
10. APPENDIX 
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SAMPLE FORMAT "E" 


Specification No. 

Revision No. 

Release Date 


CONTRACT END ITEM DETAIL SPECIFICATION 
(COMPUTER PROGRAM) 

PART II 

COMPUTER PROGRAM 
DESIGN 
(CEI NUMBER) 

(APPROVED NOMENCLATURE) 
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6.3.3 CPCEI Specification Addenda 

Frequently, a requirement develops for a CPCEI which 
is very similar to an existing CPCEI. When this occurs, it is 
desirable to create the new CPCEI by accomplishing minimum re- 
design of the existing CPCEI. To accomplish this, it is necessary 
to maintain visibility, throughout the design and development 
cycle, of differences in performance, design, and configuration 
requirements between the two CPCEI 1 s. This visibility can often 
be acquired and maintained by creating the specification for the 
new CPCEI as an addendum to the specification for the existing 
CPCEI . 


The use of a specification addendum presents a formal 
means of writing a specification for a new CPCEI, by changing 
the specification for an existing CPCEI in a manner which permits 
ready comparison of the exact relationship between the two CPCEI 1 s. 
This is accomplished by writing the new specification by direct 
reference to the existing specification on a paragraph-by-paragraph 
basis, recording in the new specification specific references to 
each paragraph in the existing specification and noting each 
addition, deletion, or change. Where no change is necessary, the 
phrase "no change" shall be used. The paragraph numbering between 
the two documents shall be identical, with the exception of 
paragraphs added to the new document which do not have an exact 
counter-part in the existing specification. 

A specification created in this manner is a new 
and complete specification in every sense. The method of 
preparing a specification for a new CPCEI by creating an 
addendum to an existing specification shall be used when the 
following conditions are satisfied: 

(a) There is sufficient reason to establish a direct 
relationship between the new CPCEI and an existing 
CPCEI as a basis for design and development, e.g., 
progressing from one type, model, series of a 
CPCEI to another; or when minor changes must be 
accomplished to a very limited number of components 
of a CPCEI for a specific mission. 

(b) The basic specification, to which the addendum is 
prepared, complies with the requirements of this 
exhibit with respect to format and content. 

The specification created by use of an addendum must 
be identified and maintained as a separate specification. 

Both the specification created by use of an addendum, and 
the basic specification to which the addendum is prepared, shall 
have independent change cycles. A specification change notice 
to either is not automatically a change to both. Each change 
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to either must be reviewed, and if it is desirable to change 
both the basic specification and the specification prepared 
as an addendum, two separate specification change notices 
must be prepared. 

When a new specification is created by the preparation 
of an addendum to an existing specification, ancJVddendum Notice 
shall be prepared which conforms to the format and includes the 
content required by sample format F. The Addendum Notice shall 
be the first entry in Section 2, "Applicable Documents". All 
of the entries in the Addendum Notice refer to the original CPCEI 
specification as the basic document for preparation of the addenda 
CPCEI, Each entry shall be transcribed from the title page and 
specification change log of the basic specification. 

Note; For filing and distribution, an addendum specifi- 
cation must always be accompanied by a copy of the 
specification to which it relates. See Sample 
Format "P". 
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SAMPLE FORMAT "F" 


— A DDENDUM NOTIC E — 


This Specification has been prepared as an Addendum to: 

Specification No, 

Revision 

Release Date , 

CEI No, 


FOR 

(Approved Nomenclature) 


Used With 


(PROJECT OR SYSTEM NAME) (PROJECT OR SYSTEM) 


This (addendum) specification must always be accompanied by the 
specification (above) to which it relates. 

The exact content of specification (insert same number as above) 
used as the basic document for this addendum is the revision 
referenced above plus the following specification change notices 
to specification (insert same number as above) . 
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COMPUTER PROGRAM IDENTIFICATION / 
CONTROL & ACCOUNTING 
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COMPUTER PROGRAM IDENTIFICATION , 
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COMPUTER PROGRAM IDENTIFICATION, 

CONTROL & ACCOUNTING 

1. PURPOSE 

This Exhibit provides requirements to insure that Computer 
Program Control End Items (CPCEI' s) are properly selected, 
identified, controlled, reviewed and accounted for- In 
addition, general information and guidance is provided 
to allow adequate integration of CPCEI requirements into 
the overall configuration management process, 

2 . SCOPE 

The requirements of this Exhibit provide the basis for 
managing and controlling computer program development in 
the following areas: 

a. Selection of CPCEI* s. 

b. Identification and marking. 

c. Configuration and change control. 

d. Technical Reviews and Inspections. 

e. Configuration Accounting. 

3 . APPLICABILITY 

This Exhibit is applicable during the definition, acquisition 
and operation of computer programs design, development, test 
and updating. 

4. REFERENCE DOCUMENTS 

The following exhibits of this document, and other documents 
shown form a part of this Exhibit: 

Exhibit VII "Specification Maintenance" 

Exhibit IX "Preparation of Engineering 

Change Proposals for Contract 
End Items" 

MIL-STD-480 30 October "Configuration Control - Engi- 

1968 neering Changes, Deviations, 

and Waivers" 
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5. GENERAL GUIDELINES 

5.1 Computer Program Contract End Item 

A computer program is the ordered set of instructions and 
data required to control the operation of a digital 
computer. The end product of the process required to 
produce a program is usually a punched deck of cards, 
magnetic tapes, or other physical media containing the 
ordered set in a form suitable for insertion into a 
digital computer. Under control of the instructions, the 
computer acts upon the data to perform a set of well- 
defined and logically related functions. A computer 
program contract end item (CPCEI) is defined in this 
exhibit as a computer programming end product whose 
development, as designated by the procuring agency, 
is subject to configuration management. 

5.2 Definition Phase 


A computer programming task usually requires the develop- 
ment of several programs and the data essential to other 
end items, the design constraints and practices to be 
followed in its development, and requirements for its 
qualification. These items are documented in a CPCEI 
Part I Specification . If the Part I Specification is 
produced by a contractor, it is reviewed by the 
procuring agency. Upon satisfactory completion of this 
review the Part I Specification is established as the 
Design Requirements Baseline for use in the acquisition 
phase'. Its initial function is to govern the design, 
development and testing of computer programs throughout 
the acquisition phase. Its continuing function throughout 
the system life cycle is to serve as the baseline against 
which the impact of proposed performance and design 
changes is assessed. 

5 . 3 Acquisition Phase 


The activities of the acquisition phase result in the 
development of a fully assembled CPCEI that has been quali- 
fied in a simulated environment prior to integration 
into the computer based system. It can be conveniently 
divided into two subphases : 

5.3.1 The Design Subphase 

The design process begins with a definition of 
the structure of the computer program as a whole, 
in terms of functions allocated to individual 
subprograms, storage allocation, computer program 
operating sequences , and the format of the data 
base. The preliminary design approach is re- 
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viewed at the Preliminary Design Review (PDR) 
with respect to the requirements of the Part I 
Specification, Successful completion of this 
review is prerequisite to the detailed design 
of the computer program components (CPC’s) which 
comprise the CPCEI. The design of each CPC or 
convenient groups of CPC’s is documented in a 
programming specification which is sufficiently 
detailed to enable a programmer to code and 
debug the CPC. The CPC design is then reviewed 
by the procuring agenpy in a Critical Design 
Review (CDR) . Successful completion of this 
review is prerequisite to coding the CPC. Other 
activities in the design subphase include the 
development of a test plan based on the quality 
assurance requirements of the Part I Specification , 
development of a programming standards manual based 
in part on the design requirements of the Part I 
Specification, and the initiation of formal 
change control and accounting of the Part I 
Specification. 

5.3*2 The Implementation Subphase 

During this subphase the contractor codes and 
debugs all CPC’s produces detailed test speci- 
fications, tests the CPC’s in groups until all 
the CPC’s have been assembled together, demonstrates 
the validity of the CPCEI by means of a preliminary 
qualification test in a simulated environment, 
and completes the documentation of the CPCEI. The 
completed technical description is documented in 
the Part II CPCEI Specification which contains the 
description of the overall design, the program- 
ming specifications, flow charts, and listings. 

Other documents such as operator handbooks, progress 
reports, and PERT reports are produced as appro- 
priate in the subphase. The terminating milestone 
for the implementation subphase is First Article 
Configuration Inspection (FACI) . The primary 
objectives of FACI are to determine if the CPCEI 
is properly marked and documented, and to establish 
the completed Part II Specification as the Product 
Configuration B aseline . The Part II Specification 
then serves in the operation phase as an instru- 
ment for use by government or contractor personnel 
in diagnosing troubles, adapting the computer 
program to environmental and operating requirements 
of specific site locations, and designing minor or 
major changes to the computer program system. 
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5.4 Operational Phase 

In this phase the CPCEI is integrated with the hardware 
and personnel of the computer based system, qualified 
and/or formally accepted in the system, and maintained 
between uses. The CPCEI may be modified for use in 
several installations or for use on a mission-by- 
mission basis. Change Control and accounting for both 
the Part I and Part II Specification is effected through- 
out the operational phase . 

6. SELECTION OF CPCEI ' s 

The CPCEI is typically a computer program which is one of 
many elements in a large system. In Apollo many of the required 
computer programs do not fall into this category. For example, 
a trajectory simulation program may work only within a 
computer and not with other equipment used during a mission. It 
is therefore necessary that some broad interpretations be given 
in the programs to be identified as CPCEI* s. The designation of 
which computer programs are to be subjected to the formal 
requirements of this exhibit is left to the discretion of the 
procuring agency. The designation should be made on the basis of 
criticality, cost, and need for formal control, subject to the 
following guidelines; 

a. At a minimum, operational programs used in direct 
real-time support of a mission (including training 
and prelaunch checkout) should be classified as 
CPCEI 1 s . 

In this context, "direct real-time support" means 
that the results of computer processing are used to 
monitor or control the course of the mission or 
training exercise. 

b. Certain non-real-time or offline programs, such as 
support and utility programs associated with a CPCEI, 
or data processing programs used for telemetry 
deduction, may be designated as CPCEI* s if: 

1. the status of the program directly affects 
mission schedules; 

2. changes to the configuration of the program 
directly affects the configuration of designated 
end items; or 

3. the programming effort requires a large expendi- 
ture of resources. In these cases it may be 
desirable to achieve a high level of management 
procedures . 


XIX-4 



EXHIBIT XIX 


The identification of CPCEI ' s is complicated by the multi- 
mission use of computer programs: in the Apollo program. Many 
systems rely on programmable digital computers to provide 
the flexibility required to support a rapid succession of 
diverse missions. A computer program supporting a particular 
real-time function may change radically from mission to mission. 
This characteristic must be recognized in establishing con- 
figuration management for the life cycle of the system. 

6.1 Identification Guidelines 


The degree to which a program, performing the same 
general function on a mission-to-mission basis, can 
change for each mission use may vary greatly. In some 
cases only data may change; in other cases slight 
program revisions may be required; in still other cases 
extensive modifications may result. It is difficult to 
establish rigid rules to determine if a program used in 
a particular mission should be classified as a new 
CPCEI or be considered as a change to an existing CPCEI. 
The following guidelines, however, should be followed in 
determining whether or not a program is to be re-identi- 
fied as a new end item (i.e., given a new identification 
number and defined in a new specification) : 

6.1.1 A program originally used in a particular mission 
may be modified and used without re-identification 
for a succeeding mission if: 

a) changes to its design are minor enough so 
that hew design reviews are not required. 

b) the existing specification can be conveniently 
modified by the use of Specification Change 
Notices (SCN's). 

c) the original program will not be used again. 

6.1.2 A program should be re-identified for use in 
succeeding missions if: 

a) new design reviews are required. 

b) new subfunctions requiring additional sub- 
programs are required. 

c) a change of computing equipment causes a 
significant reprogramming effort. 

d) a new specification is required to incor- 
porate extensive modifications made over a 
period of time. 

e) slight changes are required, but the original 
program will be used again. 

A series of programs which are re-identified for 
each mission use may be given the same CPCEI number 
and differentiated by the use of a unique series 
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identifier letter. Since some part of the 
program may be similar from mission to mission 
it may not be necessary to produce a completely 
new specification for each mission. A specification 
addendum referenced to some previous specifica- 
tion may be sufficient for a particular mission. 

In some instances it may be desirable fo identify 
portions of a program as separate end items. 

An executive routine, for example, may be mission 
independent, while the application programs it 
controls may change greatly from mission to mission. 
A single specification may therefore be ade- 
quate for the development of the executive, while 
a series of specifications may be needed for the 
test programs. The identification of the 
executive and test programs as separate end 
items would facilitate management control of 
this type of effort. 

In all cases, it is the procuring agency’s 
responsibility to identify which programs are new 
end items. The requirements of configuration 
management are such that some degree of 
flexibility is allowed in this process to account 
for differences in the nature of computer 
programming tasks. 

7. CONFIGURATION IDENTIFICATION 

A CPCEI is identified by a detailed specification and set of identi- 
fication numbers. 

7 . 1 CPCEI Specification 


The format and content for a CPCEI Specification is given in 
exhibit XVIII. As for hardware CEI 1 s the specification is 
divided into two parts; Part I is the "design to" document 
resulting from the requirements analysis in the definition 
phase; Part II is th^ "response to" document describing 
the product as produced in the acquisition phase. 

The Part I Specification contains performance requirements, 
design constraints, interface specifications, and test 
requirements, all of which are essential inputs to the 
contractors design efforts; the Part II Specification 
contains the overall design approach, programming 
specifications, flow qharts and program listings - informa- 
tion which is needed for the control of the design process, 
and eventually to describe the completed CPCEI. 
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Numbers must be assigned to a CPCEI, its parts, and 
its specifications to assure that these items may be 
properly identified. 


The selection of a numbering system must be consistent and 
provide unique identifiers for all items. The detailed 
requirements for the numbering system used in NASA are given 
in EXHIBIT X. 


The required CPCEI numbers are: 

7.2.1 Specification Number : consisting of a prefix code, 
a document identifier number, and a suffix code 
indicating the latest approved version of the 
document. 

7.2.2 End Item Number : the unique reference number by 
which the end item can always be identified. It 
is assigned in the definition phase as soon as 
the end item is identified. The end item number 
consists of a unique end item identifier plus a 
series number to distinguish end items within a 
series . 

7.2.3 Part Number : a number for each identified "part" 
which is within the end item. For a CPCEI, a 
"part" is defined to be the card decks, magnetic 
tapes, etc., in which the program is contained. 

A physical part as defined above may in many cases 
correspond to a logical part, a computer program 
component (CPC) . To facilitate identification: 

a) Each card deck containing a CPC is given a 
header card and a trailer card. Each card 
contains the name and number of the CPCEI 

and the name and part number of the subprogram. 
These cards are treated as comment cards by 
the assembler or compiler; that is, they have 
no program functions other than identifying 
a particular card deck. 

b) Each card is marked by a printed CPCEI number 
and a punched sequence number identifying its 
location within the deck. In a large enough 
project it is recommended that the CPCEI numbers 
be preprinted on the cards for convenience. 

The punched sequence number not only serves as 
a unique card identifier (when coupled with the 
CPCEI number) but also allows the computer or 
ADP equipment to be used in ordering a "shuffled’ 
deck of cards. 
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c) Each CPC card deck is color-coded for easy 
identification. The band or case of 

each subprogram deck is marked by the CPCEI 
number and part number. 

d) Each tape reel , tape cannister, disc, or 
other storage medium used is marked with 
the CPCEI number and part number. Where 
appropriate, the information is included 
in machine readable form for example, as 
a tape header block. 


8. CONFIGURATION CONTROL 

CPCEI Configuration control is the establishment of technical control 
points called "baselines " and the systematic evaluation, coordina- 
tion, and disposition of all proposed changes to these baselines. 

The CPCEI Specification is used to document the baselines for 
a CPCEI. There are two baselines formally established for the 
acquisition and operation of a computer program: the design 

requirements baseline , and the product configuration baseline . 

8 . 1 The Design Requirements Baseline 

The design requirements baseline, (DRB) is established 
at the beginning of the acquisition phase by procuring 
agency approval of the performance, design and quali- 
fication requirements in the Part I Specification, 

Once established, it becomes the controlling document 
for the design and testing activities of the contractor. 

Any change or addition to it must be submitted as a 
design requirements change and must be formally approved 
before the change can be designed and developed by the 
contractor. The DRB functions throughout both the 
acquisition and operation phase, although usually the 
volume of requirements changes will diminish in the 
operation phase. All approved changes to the DRB must be 
reflected in supporting technical documentation and in the 
end item itself. All proposed changes are formally sub- 
mitted as Engineering Change Proposals (ECP) . 

8 * 2 The Product Configuration Baseline 

The Part II Specification is established as the product 
configuration baseline after successful completion of the 
First Article Configuration Inspection (FACI) . At this 
time Part II is audited to determine if it adequately 
describes the fully-assembled CPCEI. From this point 
on, all changes to the Part II Specification must be 
formally accounted for and controlled. 
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8 . 3 Change Control 


The term "change" refers to any alteration to an 
established CPCEI baseline, 

8,3,1 Change Classification 

Changes to an established baseline are considered 

to be either of two types. Class I or Class II. 

8. 3. 1.1 Class I changes: changes which, because 

of their criticality, require formal 
procuring agency approval before a 
contractor can effect them. Changes are 
designated as Class I whenever one or more 
of the following is affected: 

a) Operational capability as specified 
in the baselined Part I CPCEI 
specification . 

b) Contract price or schedule. 

c) Systems equipment, computer programs, 
or facilities produced by other 
contractor (s) to the extent that the 
affected other contractor (s) must 
accomplish a change to maintain 
compatibility at the interface (s) . 

8. 3. 1.2 Class II changes: Changes which the contractor 

may effect without prior approval by the 
procuring agency and at no additional 

cost to the procuring agency. Such changes 
may include : 

a) Changes to correct editorial errors. 

b) Changes to correct computer program 
errors . 

c) Other changes of a minor nature, within 
categories specifically defined by the 
procuring agency, e.g., adaptation data 
or re-compiling within specified limits. 

The criteria given above are derived mainly 
from change processing requirements given 
in MIL-STD-4 80 , The major difference 
is in the classification of computer program 
error changes as Class II changes. Under 
strict interpretation of MIL-STD-4 80 
a computer program change of any type after 
FACI would be classified as a Class I change, 
because the corresponding product configura- 
tion baseline would also have to be changed. 
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In a computer programming effort, 
the number of these changes can be 
large even after FACI. The contractor 
must be given leeway in making such 
changes without having to wait for the 
approval of the procuring agency. To 
avoid unnecessary delays, the contractor 
*nay make the changes immediately. The 
contractor must update the Part II 
Specification to reflect the change and 
notify the procuring agency of the change. 

8.3.2 Change Processing 

The contractor initially classifies all proposed 
changes which result from his efforts. The initial 
determination is made according to guidelines given 
above and is subject to review by a representative 
of the procuring agency. Class I changes are 
documented in an Engineering Change Proposal (ECP) as 
defined in Exhibit IX. 

9. TECHNICAL REVIEWS AND INSPECTIONS 
9 . 1 Preliminary Design Review 


The purpose of the P0R is to evaluate the contractor's initial 
design approach prior to the implementation of this approach. 
This review gives the procuring agency the opportunity to 
determine early in the programming process if the contractor 
is designing a product that actually satisfies the require- 
ments of the Part I Specification. It also serves as a 
check on the compatibility of the CPCEI interfaces with 
other end items. The output of the review is either 
concurrence by the procuring agency of the design approach or 
a set of action items to be acted on by the contractor. 

The PDR is held when the contractor's design activity 
has progressed to the point where functions have been 
allocated to individual computer program components (CPC's) 
and flow charts showing the data flow between all CPC's 
have been produced. This occurs early in the design subphase 
of the acquisition phase. The following is accomplished 
in the PDR: 

a) The compatibility of the selected design approach 

with Part I of the CPCEI Specification is established. 
This is accomplished by review of flow charts, storage 
allocation charts, timing estimates > descriptions of 
significant algorithms, and other engineering documents 
as required by the procuring agency. An initial 
presentation of the information required in section 
3.1 of the Part II Specification may be used as the 
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basis for this review. 

b) The integrity of the design approach is established. 
This is accomplished by review of algorithms , proposed 
programming techniques, design simulation results, 
estimated storage requirements, etc. 

c) The compatibility of the CPCEI with other computer 
programs, or equipment external to the computer in 
which the CPCEI is used, is established. This is 
accomplished by review pf proposed data formats, 
timing constraints, interface drawings, and other 
systems engineering documents as determined by the 
procuring agency. 

9 . 2 Critical Design Review (CDR) 

After approval of the preliminary design approach, the 
contractor will design, in detail, each computer program 
component identified at the PDR. This design activity 
results in programming specifications which are the basis 
for detailed flow charting, coding, and testing for the 
CPC's. Prior to "release" to a programmer, the program- 
ming specification must be reviewed by the procuring agency 
to determine if the CPC has been properly designed accord- 
ing to the requirements of the Part I Specification. The 
successful completion of this review, the Critical Design 
Review (CDR) , is prerequisite to coding of the CPC by the 
contractor (except for any coding which may be required for 
the purposes of the CDR) . 

In a large system several CDR 1 9 may be required, since the 
individual CPC's will be designed over a period of time. 

It is the responsibility of the procuring agency to 
schedule the CDR*s so that the contractor's design 
activities can be expedited. Several CPC's may be reviewed 
at a single CDR. A particular CDR may be accomplished 
solely by a review of technical documents or may require 
the participation of contractor personnel depending on the 
complexity and criticality of the CPC's. In all cases the 
contractor must have available as a minimum: 

a) documents which establish the interface relationship 
between the CPC and ins environment; and 

b) that portion of Section 3.2 of the CPCEI Specification 
Part II which pertains to the CPC. This information, 
which may be in draft form when approved, will serve as 
the programming specification for the CPC, 

Other information that may be required, includes: 

a) test results for selected algorithms, or 

b) simulation results indicating the feasibility and 
integrity of the CPC design approach. 
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The CDR 1 s are held prior to committing the CPC design to 
coding and debugging* The following is accomplished as 
a part of the CDR’ss 

a) The compatibility of the CPC design with the requirements 
tested in the Part I CPCEI Specification is establish- 
ed, and the integrity of the design is evaluated. 

b) The system compatibility of the CPC design is 
established by comparison of applicable interface 
control documents . 

The result of a CDR is either approval by the procuring 
agency of the CPC design or a set of action items requiring 
effort by the contractor. 

9 . 3 First Article Configuration Inspection (FACI) 

FACI establishes the adequacy of the Part II Specification 
as an accurate and complete description of the CPCEI. The 
primary product of FACI is formal acceptance by the procuring 
agency of Part II of the CPCEI Specification as an audited and 
approved document which constitutes the product configuration 
baseline. During FACI, the audit is accomplished by 
establishing the exact relationship of the CPCEI to its detail- 
ed technical description in the Part II CPCEI Specification. 

In general, FACI is held upon completion of the Part II 
CPCEI Specification and preliminary qualification testing 
of the CPCEI in a simulated environment. If the CPCEI 
is developed at the contractor’s facility for subsequent 
shipment to the user’s facility, FACI should be held prior 
(and prerequisite) to this shipment. If the CPCEI is 
developed at the user’s facility, FACI should be held 
prior to final qualification testing of the computer 
based system. The contractor must have available at FACI: 

a) The Part II CPCEI Specification; 

b) the card decks, tapes, etc., properly marked, which 
contain the CPCEI; 

c) the results of preliminary qualification tests; and 

d) additional engineering documents as required by the 
procuring agency. 

The following is accomplished as a part of each FACI for 
CPCEI ’ s : 

a) The configuration of the CPCEI as evidenced by 

identification markings on the tapes and card decks 
involved compares directly to the Part II CPCEI 
Specification. The existence of each program component 
(i.e., subprograms) and part (tapes, card deck, etc.) 
of the implemented CPCEI is verified. 
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b) The completeness of the Part II Specification is 
verified (i.e., Part II must be complete and must 
describe the CPCEI to the procuring agency's satis?" 
faction) . All changes resulting from FACI must 

be incorporated before Part II is approved. The 
audited Part II Specification then becomes the 
product configuration baseline, 

c) The results of preliminary acceptance testing 
(tests of the entire CPCEI in a simulated environ- 
ment) are audited to determine : 

1, the status of the CPCEI as a working system element, 

2, the validity of the qualification test results, 

3, if all modifications resulting therefrom have been 
incorporated in the Part II CPCEI Specification. 

d) Where the procuring agency has ordered delivery of 
specific configuration management records of the 
CPCEI, such data is audited by direct comparison of 
the information contained in the Part II Specification, 

e) The contractor's computer program release system and 
change control procedures are reviewed and validated. 

9.4 Post-FACI Reviews 


The procuring agency may require a series of post-FACI 
reviews. These reviews are held to: 

a) ensure that all changes to the CPCEI since FACI have 
been properly incorporated and accounted for? and 

b) determine if the CPCEI can be certified as ready for 
use in a mission. This is accomplished by review of any 
major design changes since FACI and by review of final 
qualification test results. 

The manner, type and number of these reviews is left to the 
discretion of the procuring agency; but, as a minimum, one 
review shall be held prior to use in a mission. The end result of 
this review is acceptance of the CPCEI for mission use. This 
review is usually held as part of an overall review for the system 
in which the CPCEI operates. 

10. CONFIGURATION ACCOUNTING 

In order to maintain CPCEI Configuration Status to the degree 
necessary for effective configuration control, the contractor 
must prepare and update change documentation, keep an index of 
all maintained items, and a description of the components of 
the CPCEI. See Exhibits VII and IX. 

10.1 Version Description Document 

A version Description Document is used to accompany the 
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release of a CPCEI or any part thereof. It contains 
the identification of the computer program element 
delivered, and includes pertinent additional informa- 
tion relating to status, and usage. This includes: 

a) element identification (by name and number) ; 

b) inventory of material contained (e.g., tapes, 
decks of the CPCEI, ability programs, support 
problems, documentation) ; 

c) a list of all Class I and II changes; 

d) interface capability and adaptation instructions; 

e) operational description; and 

f) installation instructions. 

10.2 CPCEI Maintenance 

In addition to change paper generated for each error 
correction (after FACI) , the following accounting 
procedures are required to protect the CPCEI and ensure 
that the Part II Specification adequately reflects the 
configuration of the CPCEI. 

a) Each time a part (subprogram card deck, master 
program tape, permanent memory, etc.) is modified, 
and successfully reassembled or recompanied, the 
suffix of its part number must be increased by one. 

In this manner the suffix serves as a version number 
for the part. A modification may encompass several 
program changes and may be reported at periodic 
intervals to minimize paper work. 

b) The appropriate documents (including the listings) 
must be updated to reflect the number and configuration 
of the modified part. 

c) Where appropriate, one master card deck and two 
copies of the latest version of the CPCEI master 
tapes shall be maintained. In addition, the two 
previous versions of the master tape(s) shall be 
maintained with appropriate listings. 
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PREPARATION OF INTERFACE CONTROL 
DOCUMENTATION AND INTERFACE 
REVISION NOTICES 


1. PURPOSE 

This Exhibit provides NASA Apollo organizations and contractors 
with requirements and guidance for the preparation of Apollo 
Program Interface Control Documentation (ICD) and revisions 
thereto/ Interface Revision Notices (IRNs) . 

2 . SCOPE 

These instructions define the content of the following 
documentation which pertains to Apollo Program Interface 
Management and for its coordination approval and implementation. 

a. Interface Control Documentation (ICD) 

b. Interface Revision Notice (IRN) 

3c APPLICABILITY 

An Interface Control Document (ICD) shall be prepared and 


implemented for each Apollo Program interface. Each ICD shall 
include both sides of each interface and shall be physically, 
functionally and procedurally compatable between interfacing 
centers, applicable contractors and applicable specifications. 
This Exhibit is applicable to all NASA centers and their con- 
tractors . 

REFERENCE 

DOCUMENTS 

EXHIBITS: 

I 

Preparation of Program, Progect and System 
Performance and Design Requirements 
Specifications 


II 

Preparation of Contract End Item Detail 
Specification (Prime Equipment) 


III 

Preparation of Contract End Item Detail 
Specification (Facility) 


IV 

Preparation of Contract End Item Detail 
Specification (Identification Item) 


V 

Preparation of Contract End Item Detail 
Specification (Requirement Items) 


VI 

Preparation of Detail Specification 
( Cri ti cal Componen t s ) 


IX 

Preparation of Engineering Change Proposal 
for Contract End Items 
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XI Requirements for Configuration Identifi- 

cation and Acceptance of Contract End 
Items and Related Data 


XIV Formal Configuration Management Reviews, 

Inspection, and Demonstrations 

XVI Configuration Identification and Accounting 
Reports Requirements 

XVII Explanation of Items 

5. EXPLANATION OF TERMS 

See Exhibit XVII 

6 . PROCEDURAL REQUIREMENTS 

6 . 1 Background Information 

Interface areas are normally identified during preparation 
of Part I of the applicable specification (s) . They are 
documented, technically coordinated to assure that 
compatability exists between the interfacing areas, approved 
technically and by Configuration Control Board (CCB) action, 
incorporated by reference in Part I of the applicable 
specifications, implemented by affected centers and con- 
tractors , and are subject to Class I change control upon 
approval. 

6 . 2 General Requirements 

6.2.1 Type of Interfaces All physical interfaces, and 
related functional and procedural interface 
requirements are to be reflected within each 
interface area identified. Technical analysis 
of the conditions within each area shall determine 
the interfaces to be controlled. 

6. 2. 1.1 Physical Interfaces are those interfaces 
involving the mechanical assembly and 
spatial relationship between intercon- 
necting parts of Inter-Center Contract 
End Items (CEI*s). The requirements 
include physical and clearance envelopes 
that are established to avoid interferences 
and to permit access. 

6.2.1. 2 Functional Interfaces are those interfaces 
related to physical interfaces involving 
specific system design characteristics. 

The requirements include structural loads, 
fluid flows, and electrical circuit 
characteristics; as well as those inter- 
faces involving the interaction or 
influence of conditions imposed by one 
system or component upon another, or from 
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external sources, e.g. , shock, vibration, 
heat transfer, acoustics, pressure, 
radiation, atmospheric abberations , etc, 

6, 2, 1.3 Procedural Interfaces are those interfaces 
related to physical interfaces involving 
the sequence of events occuring in the 
assembly, alignment, service, maintenance, 
test and operation Of related systems, 
hardware, and domputer programs. 

6.2.2 Preparation - Interface Control Documentation or 
revisions thereto, shall be prepared so as to 
include only the essential information required 
to completely define the interface. The following 
criteria shall be used to define the necessary 
information to be included: 

6. 2.2.1 All design criteria and design require- 
ments which establish the overall tech- 
nical direction for hardware and soft- 
ware interface design, describing the 
general parameters and constraints, 
including limits and tolerances, under 
which the hardware and software must 
function. 


6. 2. 2. 2 Physical and functional design details, 
and operational and procedural require- 
ments including their limits and toler- 
ances, the changing of which will have 
an impact on hardware or software, per- 
formance, cost or Schedule accomplish- 
ments, (information that must be 
controlled through CCB 1 s at all affected 
Centers to assure that all sides of the 
interface are fully coordinated) . 

6. 2. 2 .3 The ICD shall not include information 
Such as operational or procedural require- 
ments that by nature normally vary up 
until the launch date, and does not make 
control between Centers practical or necessary* 


6*2.3 Origination and Changes 


6.2,3, 1 Origination of ICDs - An interface Control 
Document, or changes thereto, may be 
originated at any Center or by any of its 
contractors. When originated by a con- 
tractor it shall be a part of an Engineering 
Change Proposal (ECP) . 


6.2. 3.2 Changes to ICDs - Contractor originated 
changes will be submitted as Preliminary 
Interface Revision Notices (PIRN's) and 
received as a part of an ECP change pack- 
age by the applicable Center CCB's. All 
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PIRN's shall be routed by the CCB to the 
organization Panel Chairman or Co-Chair- 
man (at the Center receiving the ECP) 
for review and evaluation. A copy of 
the ECP (s) shall accompany the PIRN's 
and the change (s) shall be handled as a 
package. Approved PIRN's may become 
IRN ' s . 

6. 2 .3.3 Ef fectivities - Ef fectivities for ICD's/ 

IRN 1 s shall be assigned to, and on, each 
ICD/IRN for the Apollo Program end items 
for which the Center is responsible. 

Where ef fectivities cover "subsequent" 
items, the ICD/IRN shall note all appli- 
cable ef fectivities . 

6.2.3. 4 Approval - Each ICD or IRN shall be sub- 
mitted to the appropriate Panel Co-Chair- 
men or Senior Representatives. The Panel 
Chairman first receiving the document will 
apply the Apollo Interface Control Document 
form decal, which provides a signature 
block for the approval signatures of the 
Panel Co-Chairmen or Senior Representatives. 
Differences must be worked out by the Co- 
Chairmen and Senior Representatives until 
all concerned have evidenced their approval 
by signature, or the document is invali- 
dated and returned to the originator with 
appropriate comment. The Panel Co-Chairmen 
will forward approved documents to each 
affected Center Level II CCB(s) for approval/ 
disapproval and implementation by CCBD. 

6.2.4 Implementation - Once approved by the affected Apollo 
Program Manager (Center) CCB's (and forwarded to the 
Repository for release) ICD's and approved changes 
(IRN's) thereto shall be unilaterally implemented by 
the appropriate Center/Project contracts office 
against the affected contractor (s) . Contractor im- 
pact response shall be in the form of ECP's submitted 
to affected CCB's thru established contractual 
channels. Where major impacts might be expected, 

the Centers, unless implementation is directed by 
the Apollo Program Director CCB, may request con- 
tractor (s) impact (s) in the form of an ECP(s) and 
resolve Inter-Center incompatibilities thru joint 
Apollo Program Management, CCB action, or by forwarding 
recommendations to the Apollo Program Director CCB 
for resolution prior to implementation. 

6.2.5 Interface Revision Notice (IRN) Processing - Inter- 
face Revision Notices (IRN's) shall be used to doc- 
ument approved changes against an approved ICD. 
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Technical and program approval of an IRN will 
result in incorporation of the IRN in a subse- 
quent revision of the ICD. 

6. 2. 5.1 Interface Control Document Revisions 
shall be prepared to incorporate only 
approved IRN's in an ICD* Each revision 
shall be alpha-designated and shall indi- 
cate the identity of the change. 

6. 2. 5. 2 After Panel approval, IRN's and revised 
ICD's shall be submitted for approval to 
affected CCB's in accordance with estab- 
lished change procedures. 

6.2.6 ICD Maintenance - A revision to an ICD shall be 

made to incorporate approved IRN's when a maximum 
of six approved IRN’s are outstanding or any IRN 
is outstanding for 90 days. 
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